I'll provide some context and pointers that readers may find helpful to participate in the discussion and vote. - terminology: https://deploy-livedoc--sagemath.netlify.app/html/en/developer/packaging#package-types - tooling: https://deploy-livedoc--sagemath.netlify.app/html/en/developer/packaging#utility-script-to-create-and-maintain-packages
A "normal" or "wheel" package is always pinned to a specific version in the Sage distribution (package-version.txt, checksums.ini), and the Sage distribution needs to have a package for each of its dependencies. "Pip" packages can either be pinned to a specific version, or set acceptable version ranges, or be entirely unconstrained. This is set in the file requirements.txt in the package directory. Pinning a version has the potential benefit of stability (avoiding retroactive breakage by new, incompatible versions. The cost is that updating the version requires work by two Sage developers: One who prepares a PR and one who reviews it. (I'll make an attempt to quantify this cost in a separate post.) And when the package does not get the attention of developers who upgrade it, there's the potential risk of missing out on bugfixes made in newer versions, or missing out on features in major new versions. Not pinning the version has the obvious potential benefit of always being up to date. But there is a risk of instability, either by the package itself being affected by bugs in a new version, or by breaking compatibility with Sage. What policy is best for a package obviously depends on lots of factors, including the development velocity and quality control that the upstream project, interest by Sage developers in the package, the depth of integration in Sage etc. I suggest to subject "one-size-fits-all" approaches to a healthy dose of critical thinking. Dependencies of a "pip" package do not need to be available as packages in the Sage distribution. However, if a dependency is also a package of the Sage distribution, then we must declare this dependency. If we don't, surprising things can happen when building or upgrading. When new versions of "pip" packages add dependencies that happen to be Sage packages, there is a separate source of instability. On Sunday, February 11, 2024 at 11:23:42 AM UTC-8 Dima Pasechnik wrote: > Currently the standard packages cannot be pip packages, i.e. we must, in > effect, vendor them. This entails an extra effort which is often not > needed, in particular as we patch only very few Python packages. > Pip packages are on the other hand installed straight from PyPI. > > Good examples of standard packages which can become pip ones are tox, > pytest (not yet standard). > > > The other difference is that by default these packages are not included in > the Sage releases source tarball. > > Rather than adding them there I propose to split the upstream/* part of > the tarball into something optional - which is represented by a list of > files to download, and which is just not needed if you build while > connected to the internet. > > This is a huge saving on the tarball size: with upstream/* in, Sage 10.2 > tarball is 1.3Gb, and without it is smaller than 0.25Gb. > > Note that as William writes, the desire to have Sage buildable without an > internet connection was a requirement by a past Sage funder, gone about 10 > years ago. Thus there's no longer an obligation to have this option. > I am not aware of a similar to Sage which provides tarballs allowing for > an offline build. > > Thus, I would like to call a vote on these two topics: > > 1) allow standard packages to be pip packages > > 2) drop the contents of upstream/ from the Sage source tarballs. > > > --- > Dima > -- 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/b4df2e03-3eda-42a7-a7b7-07355b60c7d3n%40googlegroups.com.
