On Thu, Apr 27, 2023 at 2:15 AM Matthias Koeppe
<matthiaskoe...@gmail.com> wrote:
>
> 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 is no "mystery HPC cluster" on the list of platforms supported
by Sage. I don't see a point in "what if" argument like this.
We know it's not possible to build a modern gcc using gcc5 or whatever
outdated thing there can be, and let us leave this
potential (and very small) segment alone.
> 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.)
At this point, you start contradicting yourself. There is no value,
only added costs of maintainance, in carrying on with spkgs for which
viable alternatives are available, and such packages may be dropped
from Sage, one at a time, with no loss whatsoever.
Primary candidates here are python3 and gcc, packages you refuse to
drop due to "lack of greater plan".
But there is no greater plan needed here, these are just dead meat
which only gets used in automated testing, if at all.
We have spent years running in a vicious circle of endless upgrades of
packages we can use from the OS, such a waste.
So my proposal is to drop python3 and gcc spkgs immediately, and
gfortran upon a bit of investigation (only needed on macOS).
The next in line will be jupyter and friends.
>
> 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.
We already have developer burnout, I myself am a prime example.
Dima
>
> 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.
--
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/CAAWYfq0Ly-3fJkCH5HnyU%3DL_HLQ4%3Dw6GCNXZsuDGQgBNGdO%3Dow%40mail.gmail.com.
