On Fri, May 26, 2023 at 6:15 PM Oscar Benjamin
<oscar.j.benja...@gmail.com> wrote:
>
> On Fri, 26 May 2023 at 16:19, William Stein <wst...@gmail.com> wrote:
> >
> > On Fri, May 26, 2023 at 7:57 AM <dimp...@gmail.com> wrote:
> > > > a) Sage has a dual role as a library ("project") and as a distribution. 
> > > > NEP
> > > > 29 was designed for projects, and not for software distributions.
> > >
> > > No, Sage is just a project, with lots of dependencies (way too many).
> > > It's not a software distribution in any way, it does not include
> > > essential tools to build it (e.g. no C/C++ compiler on macos).
> ...
> >
> > In the nearly two decades since starting Sage,  software distribution
> > and the Python
> > ecosystem have improved enough that there is hope that Sage could
> > transition to just
> > being a bunch of libraries, and all the distribution gets handled by some
> > third party distribution such as conda (etc.).   That's been discussed
> > with great optimism
> > recently on this list.
> >
> > I hope soon Sage isn't a distribution, but right now it still is.
>
> Usually a distribution tries to include everything so that it can
> constrain the versions. That would imply that if Sage is a
> distribution then it should also distribute its own Python or the Sage
> versions should be constrained by the Python versions. Then it would
> not be necessary for any single version of Sage to have compatibility
> with multiple versions of Python. A Linux distro does not try to
> support many different Python versions using the same versions of
> Python packages. Each version of the distro will update the Python
> version and also the version of NumPy, SymPy etc simultaneously.
>
> The intention of NEP 29 is for various libraries such as NumPy to
> coordinate on ensuring that there exists some mutually consistent set
> of versions that can be used together either right now or some time in
> the future. It isn't necessary for newer NumPy versions to support
> significantly older Python versions because if you want to use an
> older version of Python then you can just use an older version of
> NumPy (which is precisely what a distro would do in any case). There
> are then two ways that those consistent versions get used:
>
> - Some people will use Python packaging tools to install the latest
> versions of things from PyPI and the most recent versions of packages
> are designed to be consistent with the most recent versions of Python.
> - Distributions like conda or Linux distros will use some consistent
> set of older versions i.e. an older version of Python *and* older
> versions of the packages.

One big plus in favour of NEP 29 for "Sage the project" is that it
makes the number of
Python versions to support smaller. As we are trying to move to using
unvendored Python packages,
i.e. these that come with "system Python", where the latter refers to
the unvendored Python used by Sage
instead of its own Python3 (which we can already drop, as it is an
unneeded burden, just as well as gcc), it
reduces the complexity of the upstream packages to support.

And NEP 29 has very little influence on "Sage the distribution", zero, in fact.


>
> It sounds to me like Sage is trying to live in between these two
> things and potentially ends up trying to mix older and newer versions
> together which will always be painful because no one else is trying to
> make that work.
>
> What is wrong with Sage just saying that an older version of an
> operating system only works with an older version of Sage?

Not much, indeed.

>
> Maybe if you want to use the latest version of Sage on some old
> version of Debian then you should just install a newer version of
> Python first?

yes, sure. E.g. pyenv makes it easy.

Dima
>
> Sage 10 might be better than Sage 9 but Sage 9 was still good before
> Sage 10 came along. Is it so bad that someone might need to wait until
> they are ready to upgrade other things before getting the latest
> version of Sage?
>
> There are many different levels at which you can ask these questions
> about exactly which new things should be compatible with which older
> things. The purpose of NEP 29 is that there should exist some rolling
> set of consistent package versions that aligns with the releases of
> Python itself. It is then up to downstream to decide whether they want
> the latest stuff fresh off the press today or if they would rather
> wait and use 5 years old versions of things.
>
> > There are follow up discussions, just like this one, by other projects, 
> > e.g., for sympy here:
> > https://github.com/sympy/sympy/issues/21884,
>
> The situation for SymPy is very different from NumPy because it is
> really not a big burden for SymPy to support Python 3.8 being only
> pure Python.
>  SymPy's release is just a single wheel that works on any
> OS, all versions of Python, both CPython and PyPy etc. NumPy has to
> provide and test many more binaries and also uses CPython's C API
> which has bigger cost in compatibility problems across Python
> versions.
>
> That being said the cost to SymPy is not zero and in some ways
> discussions like this about which version to support can just be time
> wasted that could be spent on better things. In the SymPy issue
> Matthias suggested that it is useful for Sage if SymPy continues to
> have wider version support. Since it is not a big cost it is fine for
> SymPy to do that. Otherwise though I would probably push for SymPy
> adopting NEP 29 just because it is a documented policy and it is good
> if everyone both in the project and downstream can see a clear policy
> and knows what to expect.
>
> --
> Oscar
>
> --
> 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/CAHVvXxSj%2BdK0nRVW49VL5zLMxOw68xwSWhdDQrN%3DDqynAV%3Dvvw%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/CAAWYfq345_OmBuBVVjzo0OQQJ6Q%2BRNxcy1iYer9gNdtnsHbSsw%40mail.gmail.com.

Reply via email to