Thanks, John. But I think it's more productive to ask:
**What was/is/will be the *purpose* of maintaining the Sage distribution?**
(Historically; as of today; and looking forward by a year or two.)
Here are some of my thoughts on this question:
1. Ease of installation.
Historically, an important purpose was to make loads of software packages,
including many poorly maintained math software, easy to install.
In particular -- easy to install for a user on a shared machine ("big
department compute server") without root access.
And in particular -- on shared machines with long outdated distributions
("Department IT installed it when the machine was bought, 10 years ago.")
As of today, it is plausible that such situations still exist. There are
definitely still "shared compute server" situations (in particular, HPC
clusters) where users cannot use container technology such as Docker and
lxc, and therefore cannot use Linux distribution packaging solutions
(archlinux, debian, ...). Overall I don't think we have sufficient insights
about our worldwide user base to be sure. Here the Sage distribution still
may have a value for users. Another option is non-root installable
packaging: essentially, conda-forge (although nix and guix may be other
options). But as I wrote earlier, there are still loose ends regarding Sage
development in a pure conda environment (note that it is still marked as
"experimental"
in
https://doc.sagemath.org/html/en/installation/conda.html#using-conda-to-provide-all-dependencies-for-the-sage-library-experimental),
and also optional packages are missing.
Going forward, if the loose ends are ironed out (I'm mixing metaphors for
comical effect) and missing packages added, I think that Sage installation,
use, and development can be fully supported on top of conda-forge. This
takes engagement and work; and this could certainly be done faster if a
decision to abandon the Sage distribution on a specific release / date is
made, because then substantial resources are freed. A time frame of a year
or two could be realistic.
(I am also working on another deployment path using Python wheels, but this
is much more work than just fixing the remaining conda-forge problems.)
2. Control of dependencies and the "many upstreams - many downstreams"
problem.
For Sage developers, the Sage distribution is a way to have direct control
over all dependencies -- that's the Sage distribution's role as a
"reference distribution".
(This role has been weakened since we introduced the spkg-configure
mechanism of working with system packages, of course. This is an activity
that does make sense one package at a time, but details such as how strict
we are in what we accept from the system matter; see Michael's thoughts in
his message.)
But still the following points apply:
a) If a critical bug is discovered, we can patch it and don't have to rely
on people and infrastructure "outside the project" to fix things for us.
Of course, we have been very lucky that packagers for many distributions
have been consistently highly engaged with the project; but this is not
something that we can take for granted.
b) And, of course, more Sage developers can become contributors to the
packaging communities; but there is the real danger that taking care of
both upstream development *and* downstream packaging for the same project
can lead to developer burnout.
c) There is a danger that our project's endorsing of a particular packaging
solution (e.g. conda-forge) could alienate highly engaged packagers for
other systems. And if left unchecked, it could also lead to the
re-introduction of code that is too tightly coupled with the specifics of
conda-forge packaging.
On Wednesday, April 26, 2023 at 3:52:43 PM UTC-7 John H Palmieri wrote:
> In an attempt to make this less of a religious war and more akin to
> something like a rational discussion:
>
> - The status quo is that we include Python3 and gcc. If you want to argue
> for their removal, you need to provide evidence that this will not cause
> problems for people on supported platforms. What's the evidence? In
> addition, what sort of evidence would convince you to change your mind and
> admit that these packages need to be kept for a while longer?
>
> - On the other side of the coin, if you have opposed removing these
> packages, what sort of evidence would convince you to change your mind and
> admit that these packages can be removed from the Sage distribution?
>
>
> On Wednesday, April 26, 2023 at 3:27:36 PM UTC-7 Matthias Koeppe wrote:
>
>> On Wednesday, April 26, 2023 at 1:46:41 PM UTC-7 Dima Pasechnik wrote:
>>
>> On Wed, Apr 26, 2023 at 9:06 PM Matthias Koeppe
>> <matthia...@gmail.com> wrote:
>> > 2. I'm not in favor of chipping away 1 package at a time in the name of
>> unsubstantiated, vague notions that a package is "ballast slowing down
>> Sage's progress".
>>
>> It's not vague, it's very concrete. It has been done in the past, cf
>> e.g. R/rpy2, tar, etc., it can be continued just fine.
>>
>>
>> Right, each of these was separately and concretely substantiated with
>> facts.
>> - tar was dropped after it was found that on all supported platforms, the
>> standard system tar did the job.
>> - R/rpy2, as I just explained in a message above.
>>
>> For context for the general readership of this list:
>> gcc/gfortran/python3 are directly tied to what platform support we can
>> claim (note that gcc/gfortran are the same package except for how the
>> scripts are called).
>> I document this platform support in the release tours (see
>> https://github.com/sagemath/sage/wiki/Sage-9.8-Release-Tour#sources)
>> based on the tests that run on GH Actions. Changes to platform support of
>> the Sage distribution are tracked in
>> https://github.com/sagemath/sage/issues/32074
>>
>>
--
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/875a411f-8e40-4e65-8faa-81bf91fbd858n%40googlegroups.com.
