A previous sage-devel thread led to this question, which I think is
important and timely to discuss.
**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.
--
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/fd00a6ea-5874-4bd3-9fcd-ec1462543760n%40googlegroups.com.
