On Fri, May 31, 2024 at 01:04:38PM -0400, David Roe wrote: > 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.
We already are using a Rust-based tool to improve Sage code, namely, ruff (https://pypi.org/project/ruff/) https://github.com/sagemath/sage/pulls?q=is%3Apr+is%3Aopen+ruff > 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. Well, Rust or no Rust: if you act myopically, you're doomed to do extra needless work/pay extra money. There are other reasons not to add extra wheel packages if it can be avoided: distribution bandwidth might stop being free, disk space might stop being free, other "too big to be sustainable" issues are popping up - we're having so many packages that they already scream for a proper package manager, and not a slow kludge we have instead. Dima > 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. -- 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/ZloXlBn6uIHzDkVM%40hilbert.
signature.asc
Description: PGP signature
