Re: [sage-devel] What was/is/will be the purpose of maintaining the Sage distribution?

2023-05-23 Thread Michael Orlitzky 
On Mon, 2023-05-22 at 12:50 -0700, Matthias Koeppe wrote:
> 
> On Saturday, April 29, 2023 at 1:45:31 PM UTC-7 TB wrote:
> 
> Should `sage -i pandoc`, at least in an interactive session, first 
> recommend to install it from the distro, and not default to conda? 
> 

Eventually I think the "sage" script should be relieved of the
responsibility to install distro/conda packages (both processes are
well-documented), but suggesting the distro package first seems like
the best approach for the time being. It may suggest packages that
can't be used, but that's no different than what ./configure does.

-- 
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/5c905ebc0be34c016545d9e3d5fcd37bb5bfe79b.camel%40orlitzky.com.

Re: [sage-devel] What was/is/will be the purpose of maintaining the Sage distribution?

2023-05-22 Thread Matthias Koeppe 
On Saturday, April 29, 2023 at 2:08:40 PM UTC-7 Matthias Koeppe wrote:

On Saturday, April 29, 2023 at 1:45:31 PM UTC-7 TB wrote:

Should `sage -i pandoc`, at least in an interactive session, first 
recommend to install it from the distro, and not default to conda? 


I wouldn't want "./sage -i pandoc" to ask for confirmation, but we could 
certainly have it print a note first and then users can ^C out of it if 
they want to try that.


I've opened https://github.com/sagemath/sage/issues/35669 for this

-- 
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/580c49d6-2033-49fb-b0d4-5bd0d2f34b64n%40googlegroups.com.

Re: [sage-devel] What was/is/will be the purpose of maintaining the Sage distribution?

2023-05-06 Thread tobia...@gmx.de 
What is now the plan of action?

In my experience, the conda workflow is currently already more stable than 
using sage distribution. Conda so far never failed to install a dependency 
for me (but there were some minor hick-ups with the integration in sage 
from time to time), while I was always afraid to run `make` since almost 
always some sage dependency failed to build (partly due to me using wsl).

On Sunday, April 30, 2023 at 8:45:35 AM UTC+8 Matthias Koeppe wrote:

> Sure, but these just the first few packages. Better list: 
> https://github.com/sagemath/sage/issues/35583
>
> On Saturday, April 29, 2023 at 5:10:43 PM UTC-7 Michael Orlitzky wrote:
>
>> On Sat, 2023-04-29 at 13:10 -0700, Matthias Koeppe wrote: 
>> > 
>> > This drops platform support for 32-bit Linux (see 
>> > 
>> https://github.com/sagemath/sage/wiki/Sage-9.8-Release-Tour#availability-of-sage-98-and-installation-help)
>>  
>>
>> > for these optional packages. We will need a decision if this OK. 
>> > 
>>
>> GNU info and Valgrind can be installed with the package manager on any 
>> 32-bit distro so there's no practical difference for those two. 
>>
>>

-- 
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/99f6e679-fcde-4594-8c29-0060d7cfedc7n%40googlegroups.com.

Re: [sage-devel] What was/is/will be the purpose of maintaining the Sage distribution?

2023-05-05 Thread sumaiya qureshi 
Hey All!

Please let me know I am included within the accepted organization or not?

According to Karachi, Pakistan timezone last night was my GSoC'23 result.

Please guide me through the procedure how to check my GSoC'23 result.

Name :- Sumaiya Qureshi (Karachi, Pakistan)

I opted for Improvements to mathematics interaction with the desired
organization "Oppia" within Web category.

Let me know if you all sage developers want further information regarding
myself to search my result.

Regards,
Sumaiya.

On Sun, Apr 30, 2023, 5:45 AM Matthias Koeppe 
wrote:

> Sure, but these just the first few packages. Better list:
> https://github.com/sagemath/sage/issues/35583
>
> On Saturday, April 29, 2023 at 5:10:43 PM UTC-7 Michael Orlitzky wrote:
>
>> On Sat, 2023-04-29 at 13:10 -0700, Matthias Koeppe wrote:
>> >
>> > This drops platform support for 32-bit Linux (see
>> >
>> https://github.com/sagemath/sage/wiki/Sage-9.8-Release-Tour#availability-of-sage-98-and-installation-help)
>>
>> > for these optional packages. We will need a decision if this OK.
>> >
>>
>> GNU info and Valgrind can be installed with the package manager on any
>> 32-bit distro so there's no practical difference for those two.
>>
>> --
> 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/332e5ceb-a190-45c5-931e-cdb9f5344639n%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/CAOgrLb0A75AHqZ1VTwbXX2KXR%3DdkLh%3DB_vzC8RdS7sg1f0HVug%40mail.gmail.com.

Re: [sage-devel] What was/is/will be the purpose of maintaining the Sage distribution?

2023-04-29 Thread Matthias Koeppe 
Sure, but these just the first few packages. Better 
list: https://github.com/sagemath/sage/issues/35583

On Saturday, April 29, 2023 at 5:10:43 PM UTC-7 Michael Orlitzky wrote:

> On Sat, 2023-04-29 at 13:10 -0700, Matthias Koeppe wrote:
> > 
> > This drops platform support for 32-bit Linux (see 
> > 
> https://github.com/sagemath/sage/wiki/Sage-9.8-Release-Tour#availability-of-sage-98-and-installation-help)
>  
>
> > for these optional packages. We will need a decision if this OK.
> > 
>
> GNU info and Valgrind can be installed with the package manager on any
> 32-bit distro so there's no practical difference for those two.
>
>

-- 
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/332e5ceb-a190-45c5-931e-cdb9f5344639n%40googlegroups.com.

Re: [sage-devel] What was/is/will be the purpose of maintaining the Sage distribution?

2023-04-29 Thread Michael Orlitzky 
On Sat, 2023-04-29 at 13:10 -0700, Matthias Koeppe wrote:
> 
> This drops platform support for 32-bit Linux (see 
> https://github.com/sagemath/sage/wiki/Sage-9.8-Release-Tour#availability-of-sage-98-and-installation-help)
>  
> for these optional packages. We will need a decision if this OK.
> 

GNU info and Valgrind can be installed with the package manager on any
32-bit distro so there's no practical difference for those two.

-- 
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/8cb146d13b9687f1a9b8f3c42cd8c7d8e736c8d3.camel%40orlitzky.com.

Re: [sage-devel] What was/is/will be the purpose of maintaining the Sage distribution?

2023-04-29 Thread Matthias Koeppe 
On Saturday, April 29, 2023 at 1:45:31 PM UTC-7 TB wrote:

Should `sage -i pandoc`, at least in an interactive session, first 
recommend to install it from the distro, and not default to conda? 


I missed this detail about "sage -i" in my response above.

This is an interesting idea, but is orthogonal to how the Sage distribution 
installs packages (whether using the Sage-specific install script or by 
running conda).

I wouldn't want "./sage -i pandoc" to ask for confirmation, but we could 
certainly have it print a note first and then users can ^C out of it if 
they want to try that.
"make pandoc" should definitely do neither.
The third way of installing optional packages, using "./configure 
--enable-pandoc",  already prints system package advice at the end of 
configure.


 

-- 
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/66815071-1f1f-48b4-94d1-57d2acc9dab4n%40googlegroups.com.

Re: [sage-devel] What was/is/will be the purpose of maintaining the Sage distribution?

2023-04-29 Thread Matthias Koeppe 
On Saturday, April 29, 2023 at 1:45:31 PM UTC-7 TB wrote:

On 29/04/2023 23:10, Matthias Koeppe wrote:

In this PR (https://github.com/sagemath/sage/pull/35585), the three 
optional packagesinfo, valgrind, rubiks are switched from our custom 
installation scripts to a (binary) installation from conda-forge.  

I have a naive question about the installation process. It is naive because 
I have read only part of the thread and linked PRs:

Some of the packages in #35585 (e.g. pandoc) are rather popular, and 
usually have support in a superset of Linux distros supported by Sage. 
Should `sage -i pandoc`, at least in an interactive session, first 
recommend to install it from the distro, and not default to conda?

Yes, that's exactly what this PR does. There are no changes to system 
package detection! 

Currently (without the PR), we do not have an install script for pandoc (it 
is a "dummy" package). So when the system package is not installed but the 
user insists to install it using Sage (for example by typing "make 
pandoc"), that is an error.
With the PR, "make pandoc" will use conda-forge to install it.


-- 
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/0c95a470-7123-405b-896b-6007ad32611bn%40googlegroups.com.

Re: [sage-devel] What was/is/will be the purpose of maintaining the Sage distribution?

2023-04-29 Thread TB 

  
  
On 29/04/2023 23:10, Matthias Koeppe
  wrote:


  
  In this PR (https://github.com/sagemath/sage/pull/35585),
  the three optional packagesinfo, valgrind, rubiks are
  switched from our custom installation scripts to a (binary)
  installation from conda-forge. 
  
  
  This drops platform support for 32-bit Linux (see
https://github.com/sagemath/sage/wiki/Sage-9.8-Release-Tour#availability-of-sage-98-and-installation-help)
for these optional packages. We will need a decision if this OK.
  
  
  A precedent for phasing out support for a platform in this
way was set in 2021 (Sage 9.4), when we dropped support for
optional packages on old Linux systems with GCC 4.x toolchains
(https://wiki.sagemath.org/ReleaseTours/sage-9.4#Support_for_optional_packages_on_systems_with_gcc_4.x_dropped).
  


  
  
On Saturday, April 29, 2023
  at 12:28:22 AM UTC-7 Matthias Koeppe wrote:

That's
  now https://github.com/sagemath/sage/pull/35585
  (needs review); starting with optional packages, not standard
  infrastructure packages though.
  

  
  
On Saturday, April 29,
  2023 at 12:14:56 AM UTC-7 Volker Braun wrote:

+1 to just using conda
  for all basic infrastructure packages if the host doesn't
  have them. Just put a conda env in the PATH and done.
  

  

I have a naive question about the installation process. It is
  naive because I have read only part of the thread and linked PRs:
Some of the packages in #35585 (e.g. pandoc) are rather popular,
  and usually have support in a superset of Linux distros supported
  by Sage. Should `sage -i pandoc`, at least in an interactive
  session, first recommend to install it from the distro, and not
  default to conda? For example, if a user wants to customize an
  init file of the package or already installed most dependencies of
  a package from the distro, then the installing from the distro
  might be better. Have this been discussed before?



Regards,
TB

  




-- 
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/73661032-006b-ad67-2877-1c98e9488d6c%40gmail.com.

Re: [sage-devel] What was/is/will be the purpose of maintaining the Sage distribution?

2023-04-29 Thread Matthias Koeppe 
In this PR (https://github.com/sagemath/sage/pull/35585), the three 
optional packagesinfo, valgrind, rubiks are switched from our custom 
installation scripts to a (binary) installation from conda-forge. 

This drops platform support for 32-bit Linux (see 
https://github.com/sagemath/sage/wiki/Sage-9.8-Release-Tour#availability-of-sage-98-and-installation-help)
 
for these optional packages. We will need a decision if this OK.

A precedent for phasing out support for a platform in this way was set in 
2021 (Sage 9.4), when we dropped support for optional packages on old Linux 
systems with GCC 4.x toolchains 
(https://wiki.sagemath.org/ReleaseTours/sage-9.4#Support_for_optional_packages_on_systems_with_gcc_4.x_dropped).


On Saturday, April 29, 2023 at 12:28:22 AM UTC-7 Matthias Koeppe wrote:

> That's now https://github.com/sagemath/sage/pull/35585 (needs review); 
> starting with optional packages, not standard infrastructure packages 
> though.
>
>
> On Saturday, April 29, 2023 at 12:14:56 AM UTC-7 Volker Braun wrote:
>
>> +1 to just using conda for all basic infrastructure packages if the host 
>> doesn't have them. Just put a conda env in the PATH and done.
>>
>> In my experience these work really well. I've only gotten issues with 
>> conda when you veer off the trodden path too much, e.g. I've had nothing 
>> but trouble installing ruby from conda-forge and then trying to build gems 
>> on top of that (ruby has various hard-coded compiler configuration paths, 
>> some of which point to the wrong place). 
>>
>>
>> On Saturday, April 29, 2023 at 1:25:26 AM UTC+2 Matthias Koeppe wrote:
>>
>>> On Thursday, April 27, 2023 at 1:24:01 AM UTC-7 Dima Pasechnik wrote:
>>>
>>> The next in line will be jupyter and friends.
>>>
>>>
>>> I agree with this point; specifically the front-end parts of 
>>> Jupyter/JupyterLab, which run in a separate Python process (and therefore 
>>> can be installed in a completely separate tree / venv). For this idea, we 
>>> have the the long-open metaticket 
>>> https://github.com/sagemath/sage/issues/30306 
>>>
>>> But this observation can be generalized. 
>>>
>>> For any package from which we only use executables or data, not a shared 
>>> library, we can install it in any way we want -- without compromising the 
>>> Sage distribution's ability to use already installed system packages.
>>> So we can switch from our own installation scripts to using conda-forge 
>>> for these!
>>>
>>> I've written up the details in 
>>> https://github.com/sagemath/sage/issues/35583
>>>
>>> I'm counting about 40 packages (not counting the Jupyter frontend 
>>> components) for which we can make a safe and easy withdrawal from packaging 
>>> activities, WITHOUT making the Sage distribution harder to install, and 
>>> avoiding the "concave cost" along the path that I mentioned.
>>>
>>> (Note that gcc/gfortran do not fall into this category of packages 
>>> because of their runtime library components.)
>>>
>>>

-- 
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/f0505a52-a005-492f-b7c7-c9a92b69192an%40googlegroups.com.

Re: [sage-devel] What was/is/will be the purpose of maintaining the Sage distribution?

2023-04-29 Thread Matthias Koeppe 
That's now https://github.com/sagemath/sage/pull/35585 (needs review); 
starting with optional packages, not standard infrastructure packages 
though.


On Saturday, April 29, 2023 at 12:14:56 AM UTC-7 Volker Braun wrote:

> +1 to just using conda for all basic infrastructure packages if the host 
> doesn't have them. Just put a conda env in the PATH and done.
>
> In my experience these work really well. I've only gotten issues with 
> conda when you veer off the trodden path too much, e.g. I've had nothing 
> but trouble installing ruby from conda-forge and then trying to build gems 
> on top of that (ruby has various hard-coded compiler configuration paths, 
> some of which point to the wrong place). 
>
>
> On Saturday, April 29, 2023 at 1:25:26 AM UTC+2 Matthias Koeppe wrote:
>
>> On Thursday, April 27, 2023 at 1:24:01 AM UTC-7 Dima Pasechnik wrote:
>>
>> The next in line will be jupyter and friends.
>>
>>
>> I agree with this point; specifically the front-end parts of 
>> Jupyter/JupyterLab, which run in a separate Python process (and therefore 
>> can be installed in a completely separate tree / venv). For this idea, we 
>> have the the long-open metaticket 
>> https://github.com/sagemath/sage/issues/30306 
>>
>> But this observation can be generalized. 
>>
>> For any package from which we only use executables or data, not a shared 
>> library, we can install it in any way we want -- without compromising the 
>> Sage distribution's ability to use already installed system packages.
>> So we can switch from our own installation scripts to using conda-forge 
>> for these!
>>
>> I've written up the details in 
>> https://github.com/sagemath/sage/issues/35583
>>
>> I'm counting about 40 packages (not counting the Jupyter frontend 
>> components) for which we can make a safe and easy withdrawal from packaging 
>> activities, WITHOUT making the Sage distribution harder to install, and 
>> avoiding the "concave cost" along the path that I mentioned.
>>
>> (Note that gcc/gfortran do not fall into this category of packages 
>> because of their runtime library components.)
>>
>>

-- 
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/fd53eefb-dbfc-4a74-9242-1ba7a2ff50ffn%40googlegroups.com.

Re: [sage-devel] What was/is/will be the purpose of maintaining the Sage distribution?

2023-04-29 Thread Volker Braun 
+1 to just using conda for all basic infrastructure packages if the host 
doesn't have them. Just put a conda env in the PATH and done.

In my experience these work really well. I've only gotten issues with conda 
when you veer off the trodden path too much, e.g. I've had nothing but 
trouble installing ruby from conda-forge and then trying to build gems on 
top of that (ruby has various hard-coded compiler configuration paths, some 
of which point to the wrong place). 


On Saturday, April 29, 2023 at 1:25:26 AM UTC+2 Matthias Koeppe wrote:

> On Thursday, April 27, 2023 at 1:24:01 AM UTC-7 Dima Pasechnik wrote:
>
> The next in line will be jupyter and friends.
>
>
> I agree with this point; specifically the front-end parts of 
> Jupyter/JupyterLab, which run in a separate Python process (and therefore 
> can be installed in a completely separate tree / venv). For this idea, we 
> have the the long-open metaticket 
> https://github.com/sagemath/sage/issues/30306 
>
> But this observation can be generalized. 
>
> For any package from which we only use executables or data, not a shared 
> library, we can install it in any way we want -- without compromising the 
> Sage distribution's ability to use already installed system packages.
> So we can switch from our own installation scripts to using conda-forge 
> for these!
>
> I've written up the details in 
> https://github.com/sagemath/sage/issues/35583
>
> I'm counting about 40 packages (not counting the Jupyter frontend 
> components) for which we can make a safe and easy withdrawal from packaging 
> activities, WITHOUT making the Sage distribution harder to install, and 
> avoiding the "concave cost" along the path that I mentioned.
>
> (Note that gcc/gfortran do not fall into this category of packages because 
> of their runtime library components.)
>
>

-- 
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/5b0f815b-9557-4bc3-8eb7-8ec3122df5d8n%40googlegroups.com.

Re: [sage-devel] What was/is/will be the purpose of maintaining the Sage distribution?

2023-04-28 Thread Matthias Koeppe 
On Thursday, April 27, 2023 at 1:24:01 AM UTC-7 Dima Pasechnik wrote:

The next in line will be jupyter and friends.


I agree with this point; specifically the front-end parts of 
Jupyter/JupyterLab, which run in a separate Python process (and therefore 
can be installed in a completely separate tree / venv). For this idea, we 
have the the long-open 
metaticket https://github.com/sagemath/sage/issues/30306 

But this observation can be generalized. 

For any package from which we only use executables or data, not a shared 
library, we can install it in any way we want -- without compromising the 
Sage distribution's ability to use already installed system packages.
So we can switch from our own installation scripts to using conda-forge for 
these!

I've written up the details in https://github.com/sagemath/sage/issues/35583

I'm counting about 40 packages (not counting the Jupyter frontend 
components) for which we can make a safe and easy withdrawal from packaging 
activities, WITHOUT making the Sage distribution harder to install, and 
avoiding the "concave cost" along the path that I mentioned.

(Note that gcc/gfortran do not fall into this category of packages because 
of their runtime library components.)

-- 
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/76ee02da-b86d-4d83-975e-27db5ca6b130n%40googlegroups.com.

Re: [sage-devel] What was/is/will be the purpose of maintaining the Sage distribution?

2023-04-27 Thread Dima Pasechnik 
On Thu, Apr 27, 2023 at 2:15 AM Matthias Koeppe
 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,

[sage-devel] What was/is/will be the purpose of maintaining the Sage distribution?

2023-04-26 Thread Matthias Koeppe 
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.