On Fri, May 31, 2024 at 12:38 PM Dima Pasechnik <dimp...@gmail.com> wrote:
> On Thu, May 30, 2024 at 11:25 PM Matthias Koeppe > <matthiaskoe...@gmail.com> wrote: > > > > We added the packages as optional "pip" packages (see > https://deploy-livedoc--sagemath.netlify.app/html/en/developer/packaging#package-types > for the terminology), each more than 1 year ago. > > > > - > https://deploy-livedoc--sagemath.netlify.app/html/en/reference/spkg/pytest#spkg-pytest > (added in 2020) > > - > https://deploy-livedoc--sagemath.netlify.app/html/en/reference/spkg/pytest_mock#spkg-pytest-mock > (added in 2022) > > - > https://deploy-livedoc--sagemath.netlify.app/html/en/reference/spkg/pytest_xdist#spkg-pytest-xdist > (added in 2022) > > > > "pytest" is the current gold standard for running tests of Python > packages. Various standard packages in the Sage distribution already > declare pytest in "dependencies_check" as a conditional dependency for use > when SAGE_CHECK=yes is set. The support for testing parts of the Sage > library with pytest was from an effort largely stalled after 2022 -- and > which has been completely broken since early 2024 with the arrival of > pytest 8.x, which I have just fixed in > https://github.com/sagemath/sage/pull/37999 (to be merged). I'll note > that recent versions of pytest have added support for PEP-420 implicit > namespace package, which the Sage library uses as part of the > modularization effort. > > > > By making pytest a standard package, I would hope to help revive this > effort, and thus the larger effort to "adopt mainstream Python > testing/linting infrastructure" (see > https://github.com/sagemath/sage/issues/28936). > > > > I'm proposing to make the packages (and their dependencies) standard > (wheel) packages according to the procedures in our developer guide. > > - Reference to previous such proposals following our project's > procedures: > https://groups.google.com/g/sage-devel/c/EMeTJ6Hwgns/m/KyOOQzkzAAAJ > > - Link to our packaging documentation and explanation how making it a > standard package compares to version pinning done for example using > conda-lock: > https://groups.google.com/g/sage-devel/c/MIU-xo9b7pc/m/N2vuKb-TAAAJ > > > > The other pytest_* packages are related technical packages. > > The PR that implements it: https://github.com/sagemath/sage/pull/37301 > > > > This is a redo of the 2nd part of my proposal > https://groups.google.com/g/sage-devel/c/MIU-xo9b7pc/m/NsyUa7iXAgAJ from > Feb 10, which was stalled. (The 1st part (on python_build) was redone in > https://groups.google.com/g/sage-devel/c/EMeTJ6Hwgns/m/9_zh6usoAAAJ and > approved.) > > My objections (and not only my) to this still stand - and, frankly, I > don't see anything new here. What's the point of bringing the stalled > matters up again in this original unchanged way ? > > We don't need to have all the dependencies of packages like pytest in > Sage, it's just pure bloat, give their peripheral role in particular. > That is, it's fine to declare them standard, and keep them pip > packages - what do we lose this way? Nothing, and we don't bloat Sage > with even more packages nobody knows anything about - besides them > being dependencies of something in Sage. > > But there is more trouble ahead if the currect proposal gets in over > my objections. Say, the next version of pytest might get a part which > needs Rust, and pytest is a wheel package, with all its buildable from > source dependencies in Sage, and Sage is fully committed to using > pytest for testing. > Are you going to include a Rust toolchain in Sage ? No, obviously not. > Are you going to demote pytest back to optional, > and throw away work done on using pytest more? No. Have another fight > over the ways Sage should be packaged? Yes, sure. > I don't find it plausible that a package whose purpose is to test Python code would add Rust as a dependency. Sure, dependencies can change as projects evolve and add features, but I don't think it's reasonable to base decisions on what to add to the sage distribution on potential future changes. David I think the only feasible way forward here is as I proposed (standard > pip packages), and I propose it again. > > Dima > > > > > > > I ask everyone to focus on the specifics of this proposal. > > > > -- > > You received this message because you are subscribed to the Google > Groups "sage-devel" group. > > To unsubscribe from this group and stop receiving emails from it, send > an email to sage-devel+unsubscr...@googlegroups.com. > > To view this discussion on the web visit > https://groups.google.com/d/msgid/sage-devel/2c42bd41-24a3-467e-857f-aedc3966c107n%40googlegroups.com > . > > -- > You received this message because you are subscribed to the Google Groups > "sage-devel" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to sage-devel+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/sage-devel/CAAWYfq2fubG32GKjKroEVJ_LKB2WUY%2BqJSXCZTgd0ROC%3DYHczA%40mail.gmail.com > . > -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/CAChs6_kCgBRXMZWtptJPfDpOqbxTXF2gdeQJ8%3D-oNGRrEv%2BVdw%40mail.gmail.com.
