I've reposted this last message in a separate thread.
On Wednesday, April 26, 2023 at 5:05:56 PM UTC-7 Matthias Koeppe wrote:
> 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/a38e450b-27df-4cbe-b98c-e0c7261a90d9n%40googlegroups.com.
