On 11 February 2024 21:46:40 GMT, Matthias Koeppe <matthiaskoe...@gmail.com>
wrote:
>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.
Sage had shot itself in the foot by adopting an overtly rigid approach to
Python dependencies which are not tightly integrated into the core of Sage
(sagelib): Jupyter, Tox, and Sphinx (and their zillion dependencies).
A way out of it is to declare as many deps as possible pip, and just remove
from our list many of these packages which are dependencies of Sphinx and
Jupyter only (they are found and installed by pip just fine when you install
Jupyter and Sphinx, there is no need for Sage's micromanaging of them).
The potential issues with dependencies of pip packages interfering with Sage
packages (you mention these below) are precisely the result of this package
micromanagement.
>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.
Yes, indeed, the current "standard packages cannot be pip packages" is exactly
"one-size-fits-all" approach you are arguing against, and the issue we would
like to resolve here.
>
>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.
OTOH a package like pytest or tox is basically an external tool, and using an
appropriate version of it is all what's needed.
>
>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/C93102E1-E292-4761-97B9-413BA5638A4C%40gmail.com.
