Proposal (redo): Make python_build (and its dependency pyproject_hooks) a standard package

[Matthias Koeppe]

We added python_build as an optional "pip" package (see https://deploy-livedoc--sagemath.netlify.app/html/en/developer/packaging#package-types for the terminology),

- https://deploy-livedoc--sagemath.netlify.app/html/en/reference/spkg/python_build#spkg-python-build (added in 2022).

"python_build" (a.k.a. pypa/build) is the current standard front-end for making source distributions and wheels from a Python source tree. It has replaced the deprecated practices of calling "setup.py sdist" or "setup.py bdist_wheel" directly. We already use it for building the modularized distribution packages. Making it a standard package will allow us to modernize the build infrastructure (front-end) for the Sage library in the Sage distribution.

I'm proposing to make it a standard package according to the procedures in our developer guide. Per our policy, that's a "normal" package, so its dependency pyproject_hooks will also be added. The PR is prepared in https://github.com/sagemath/sage/pull/37300 

This is a re-do of my proposal https://groups.google.com/g/sage-devel/c/MIU-xo9b7pc/m/NsyUa7iXAgAJ whose discussion was stalled by commenters bundling it with political demands. 

[Nathan Dunfield]

+1: Using the PyPA standard build tools is a good move.

[Dima Pasechnik]

As in the previous attempt, I am OK with it becoming standard only if it remains a pip package, a no new "batteries are included".

As a matter of fact, there is no point in keeping Python toolchain packages vendored. They can all be pip packages just as well.

[Matthias Koeppe]

Dima, our project does not have such a policy of not adding standard normal packages. This bundling with your political demand is inappropriate and not welcome here.

[Dima Pasechnik]

On 10 April 2024 20:23:10 CEST, Matthias Koeppe <matthia...@gmail.com> wrote:
>Dima, our project does not have such a policy of not adding standard normal
>packages. This bundling with your political demand is inappropriate and not
>welcome here.

Why is it unwelcome?
I explained under what condition I am OK with making this package standard. I could have just said NO without any explanation.

It is technical and not political. Political is your " not welcome" remark.

[Kwankyu Lee]

+1

[Matthias Koeppe]

Thanks all. 

I consider this approved.

PR https://github.com/sagemath/sage/pull/37300 is ready for review.

[Dima Pasechnik]

Please spell  out the need for yet another "battery" included.

Please also record my -1 for #37300

[Matthias Koeppe]

When I completed the NumFOCUS application yesterday, I had to go through the past years of sage-devel posts to answer the new question "Where do you host conversations about project development and governance (e.g. mailing lists, forums, etc.), and how many participants do you have?" (see https://github.com/sagemath/sage/wiki/NumFOCUS#q16-where-do-you-host-conversations-about-project-development-and-governance-eg-mailing-lists-forums-etc-and-how-many-participants-do-you-have)

While doing so, I also collected the sage-devel threads in which packages were proposed to be added as standard packages, following our project's procedures:

- "Add pplpy and gmpy2 as standard packages" (https://groups.google.com/g/sage-devel/c/qoxVng1__0A/m/4HntWHp_AQAJ, 2018-02)

- "Make giacpy_sage a standard package" (https://groups.google.com/g/sage-devel/c/uYXGzG_py28/m/4SN5hts4FQAJ, 2020-02)

- "Add tox as a standard package" (https://groups.google.com/g/sage-devel/c/G5kMggTecA8/m/2aTZSt_AAwAJ, 2020-09)

- "Making cmake a standard package" (https://groups.google.com/g/sage-devel/c/Ccumny9Yioc/m/litCsb6gAwAJ, 2021-07)

- "New standard package: GNU Info" (https://groups.google.com/g/sage-devel/c/aIx8i-0MRo4/m/4WxL64JlBAAJ, 2021-07)

- "Add more-itertools as a standard package" (https://groups.google.com/g/sage-devel/c/Dq83PiiCAsU/m/43WX3JgjDgAJ, 2021-12) 

- "Make Jupyterlab a standard package" (https://groups.google.com/g/sage-devel/c/orUpb-YXIHk/m/d_zDX3xyDQAJ, 2022-03)

- "Make Furo a standard package" (https://groups.google.com/g/sage-devel/c/VTU_I-ecPlA/m/KMd9cMX9AQAJ, 2022-08) 

- "Make ipympl a standard package" (https://groups.google.com/g/sage-devel/c/fRufANUCNdY/m/RKhnlUYdAgAJ, 2023-09)

Our project's procedures have not changed.

[Dima Pasechnik]

On 14 April 2024 19:14:51 BST, Matthias Koeppe <matthia...@gmail.com> wrote:
>When I completed the NumFOCUS application yesterday, I had to go through
>the past years of sage-devel posts to answer the new question "Where do you
>host conversations about project development and governance (e.g. mailing
>lists, forums, etc.), and how many participants do you have?" (see
>https://github.com/sagemath/sage/wiki/NumFOCUS#q16-where-do-you-host-conversations-about-project-development-and-governance-eg-mailing-lists-forums-etc-and-how-many-participants-do-you-have)
>
>While doing so, I also collected the sage-devel threads in which packages
>were proposed to be added as standard packages, following our project's
>procedures:

This is not an answer. I would like an explanation why Sage the distro has to grow the bloat at ever increasing speed, why you think it is sustainable, but, most of all, why "batteries included" is meaningful in 2024, and why these procedures must stay as they are.

I understand that some macOS users are very comfortable with Sage the distro playing the role of a missing macOS package manager, but it makes me sad that I spent many months of my time debugging and improving Sage on macOS, and getting this kind of cold shoulder in response to my requests.



Dima

[Tobia...@gmx.de]

-1

The usage of "setup.py sdist" or "setup.py bdist_wheel" only happens in certain edge cases (e.g. the almost un-documented `--enable-wheels` option) and in these cases it is no problem to require developers to run `pip install build` beforehand. So these last remaining instances of calling "setup.py" directly can easily be migrated to "build", even without "build" being a standard package. Most developers should never need the "build" module (neither directly nor indirectly) and hence having it as an optional package is good-enough in my opinion.

Also I don't see how this proposal is any different than the other one that has been discussed before.

[kcrisman]

I understand that some macOS users are very comfortable with Sage the distro playing the role of a missing macOS package manager,

The real question is about *users* in this case, not developers. I just got messed up the other day brew updating something which killed my Python 3.9 I need in order to use a specific package (nothing to do with Sage, completely orthogonal) for a certain course, a package which doesn't support the most recent Pythons yet, and frankly my teaching load (unlike perhaps that of most Sage developers, I acknowledge) doesn't leave time to learn the intricacies of pyenv or whatever there is out there to rectify such situations (I don't *mind* having 3.12 on my box ...).  Sage's "batteries included" means all my Sage installations of various vintages stay sandboxed, essentially, and that is pretty comforting.

My guess is that most Sage *users* are in this kind of situation.  The WSL solution using some version of conda now might allow something similar (?) for the VAST number of Windows users out there.  CoCalc probably provides a single solution to a large number of users too (how large, I don't know) for people using Mac and Windows in their day-to-day work, who don't mind a little Terminal to get some math done but don't want to use Linux (among other reasons, because many of us can't afford our own personal computers for work, so we have to take the options work gives us, which is emphatically not Linux).  It's great that the fairly small number of Linux users wordwide have the package manager concept, but its very fragmentation (!!!) surely takes a lot of developer time too (not just for Sage) as well.  So this argument, by itself, isn't sufficient.

  

but it makes me sad that I spent many months of my time debugging and improving Sage on macOS, and getting this kind of cold shoulder in response to my requests.

This is totally legitimate, as I've said before, and is the real crux of the issue.  I would hope people who don't want "batteries included" could live with it if there weren't a lot of unseen maintenance.  Under past circumstances, there would have been a Sage Days of some kind by now (in person) to hash out how to resolve the situation *with an acceptable consensus*, even if still imperfect, which lightens the load significantly on Linux package managers while keeping the other progress made on track.  We need something approximating this sort of summit now to resolve these issues - and I certainly do think there is an acceptable solution out there.

[Michael Orlitzky]

On 2024-04-15 04:20:59, kcrisman wrote:
>
> The real question is about *users* in this case, not developers.

The solution for users is pretty simple. You should be able to install
a sage that works and will remain working with one command using
homebrew, conda, guix, etc. The reason you can't is because Sage is,
and has always been, hostile to it.

We (not just Sage, but you and I!) have been discussing this for
almost 15 years. Based on that number you would think that packaging
involves some deep question in software architecture, but it
doesn't. I package hundreds of other programs. They're all easy to
install and work great. Sage is the _one_ project that is a PITA. If
you want to use GAP or Octave, no problem. No way to prevent this,
says only country where this regularly happens.

SageMath has several other long-term contributors who also package
software. We're all roughly on the same page about what it would take
to fix the sage installation for end users. Eventually it might make
sense to listen to the people who have succeeded at the task before.

> We need something approximating this sort of summit now to resolve these
> issues - and I certainly do think there is an acceptable solution out there.

The solution to this social problem is once again quite simple. The
people who want to work on the sage distribution should be allowed to
work on the sage distribution, and the people who don't should be
allowed not to. But so far, every attempt to disentangle the
library/distribution to enable this division of labor has been met
with resistance by essentially one person.

[Marc Culler]

On Monday, April 15, 2024 at 7:03:27 AM UTC-5 Michael Orlitzky wrote:

The solution for users is pretty simple. You should be able to install
a sage that works and will remain working with one command using

homebrew, conda, guix, etc. The reason you can't is ...

I would just mention that macOS users who have homebrew can install Sage by typing one command:

$ brew install sage

and macOS users who do not have homebrew can install Sage by downloading a disk image and dragging the SageMath app into their Application folder.  Both operations install the identical software and both produce a sage that works and will remain working and that is the most recently released version of sage.

This is true with the current configuration of Sage.

- Marc

[Dima Pasechnik]

On Mon, Apr 15, 2024 at 12:21 PM kcrisman <kcri...@gmail.com> wrote:

I understand that some macOS users are very comfortable with Sage the distro playing the role of a missing macOS package manager,

The real question is about *users* in this case, not developers. I just got messed up the other day brew updating something which killed my Python 3.9 I need in order to use a specific package (nothing to do with Sage, completely orthogonal) for a certain course, a package which doesn't support the most recent Pythons yet, and frankly my teaching load (unlike perhaps that of most Sage developers, I acknowledge) doesn't leave time to learn the intricacies of pyenv or whatever there is out there to rectify such situations (I don't *mind* having 3.12 on my box ...).  Sage's "batteries included" means all my Sage installations of various vintages stay sandboxed, essentially, and that is pretty comforting.

Pyenv is easier than sage distro, much easier.

If there was an easy way to install Sage into a pyenv environment,

one could have used it...

My guess is that most Sage *users* are in this kind of situation.

Well, depending on a legacy (3.9) Python version isn't the problem for the most, I hope. :-)

 

 The WSL solution using some version of conda now might allow something similar (?) for the VAST number of Windows users out there.

Combining WSL+conda might be a bit too sophisticated for - e.g. I'm not sure it plays well with

using VS Code to run notebooks in WSL.

Thus, one probably would do in WSL "sudo apt-get install sage-jupyter", installing Sage 9.5 - if the standard for WSL Ubuntu 22 is used). This is old Sage...

Yes, one can follow the advice in https://sagemanifolds.obspm.fr/install_ubuntu.html

to get an up to date Sage in your Ubuntu WSL.

One way or another, this involves packaging Sage for Ubuntu (current;y stalled), or for Conda (something that suffers from the same issues as other distro packaging)

 

 CoCalc probably provides a single solution to a large number of users too (how large, I don't know) for people using Mac and Windows in their day-to-day work, who don't mind a little Terminal to get some math done but don't want to use Linux (among other reasons, because many of us can't afford our own personal computers for work, so we have to take the options work gives us, which is emphatically not Linux).  It's great that the fairly small number of Linux users wordwide have the package manager concept,

the VAST number of Windows (+WSL) users have the package manager concept (in their WSL), too.

They all most probably do "sudo apt-get install sage-jupyter" if they want to run Sage.

 

but its very fragmentation (!!!) surely takes a lot of developer time too (not just for Sage) as well.  So this argument, by itself, isn't sufficient.

What fragmentation are you talking about?

Packaging even a relatively sophisticated CAS like GAP for an OS isn't a particularly hard task.

Once done, updates aren't time consuming at all.

SageMath should be easier than GAP to package, and not much harder.

And it's much harder at present, as it stubbornly refuses to be a good member of Python universe.

  

but it makes me sad that I spent many months of my time debugging and improving Sage on macOS, and getting this kind of cold shoulder in response to my requests.

This is totally legitimate, as I've said before, and is the real crux of the issue.  I would hope people who don't want "batteries included" could live with it if there weren't a lot of unseen maintenance.

Mind you, even macOS users of Sage, who use the 3-manifold app

from https://github.com/3-manifolds/Sage_macOS/releases (as recommended on

https://doc.sagemath.org/html/en/installation/#macos), so it's probably the macOS majority,

don't use most of the "batteries". E.g. they don't use packaged Jupyter.

And the VAST number of Windows+WSL users don't use packaged Jupyter.

(and they don't use Python build tools, or sphinx, or packaged compilers...)

 Under past circumstances, there would have been a Sage Days of some kind by now (in person) to hash out how to resolve the situation *with an acceptable consensus*, even if still imperfect, which lightens the load significantly on Linux package managers while keeping the other progress made on track.  We need something approximating this sort of summit now to resolve these issues - and I certainly do think there is an acceptable solution out there.

 

It has to be formulated and agreed upon in general lines, otherwise such a summit would be a waste of time.

Dima

[kcrisman]

We (not just Sage, but you and I!) have been discussing this for
almost 15 years.

Haha, true!

 

SageMath has several other long-term contributors who also package
software. We're all roughly on the same page about what it would take
to fix the sage installation for end users.

And some of these people (perhaps kiwifb?) have not been as directly involved in some of the recent disputes.   Maybe there is a path forward (I also presume the CoCC is thinking about this). 

  

But so far, every attempt to disentangle the
library/distribution to enable this division of labor has been met
with resistance by essentially one person.

Well, more accurately there must be a critical mass of people who, like Kwankyu in some recent comments (apologies for not having link to hand), want to trust that the related process undertaken by that person is worth doing, and to let that proceed.  Otherwise they would have spoken up, as many longer-term developers are not shy of doing so on other matters. 

Regarding WSL in Dima's post, I thought https://github.com/sagemath/sage/pull/37184 (and the followups) addressed this quite a bit - that was what I was referring to.  If I could get it to work, I think anyone could.  But I didn't try Jupyterlab, maybe that's not included in it.  Anyway, I was definitely not referring to anyone who knows what "apt-get" is in WSL.  So am I right in your saying that Jupyter wouldn't work "out of the box" with Sage with the conda-based solution for WSL?  To me, that's an argument *for* batteries, not against.  

Same applies for the MacOS version provided by 3manifolds, my assumption was that this would work "out of the box" if you do sage -n jupyter or something.  That assumption could be wrong - but again, why put additional barriers to the user?  "Normal" software that "normal" i.e. non-developer people use in the real world doesn't do that.  Why make that a prerequisite for just doing math?  I hate to beat the dead horse of the now-debatable mission statement, but does Mathematica make you separately download and install a notebook?   Even LaTeX has this problem - you have to install the distribution separately from TeXShop or what have you - and just like the developer friction noted here, it's a little bit of extra friction.

> What fragmentation are you talking about? 

I meant that it's a bit silly (from the Mac or Windows perspective) that one even needs Arch, Ubuntu, Debian, Gentoo, Fedora, or anything else on the massive (and probably incorrect) list on Wikipedia: https://en.wikipedia.org/wiki/List_of_Linux_distributions  That's a massive duplication of effort right there.

> It has to be formulated and agreed upon in general lines, otherwise such a summit would be a waste of time.

Agreed.  All of my points are irrelevant compared to getting us back on some consensus track.  That means toning down the rhetoric and candidly saying what sub-optimal concessions might be on the table (to be clear, for everyone).  It's clear now that at least two visions for Sage packaging/modularization which, in their current technical state, are viewed by stakeholders as colliding in their purest forms, but it seems unlikely that Sage is not Turing-complete enough to support a modus vivendi.

[kcrisman]

Pyenv is easier than sage distro, much easier.

I meant *using* pyenv.  I just don't want to be bothered when I really just use Sage.  But this is quite orthogonal to the actual discussion, sorry for bringing up my 3.9 issues :-)

Well, depending on a legacy (3.9) Python version isn't the problem for the most, I hope. :-)

Yes, absolutely not!  I meant just the whole not wanting to deal with managing different Python installations.  I don't want to manage different versions of LaTeX on my computer either.  One is plenty, thank you very much :-) 

[Dima Pasechnik]

On Mon, Apr 15, 2024 at 5:41 PM kcrisman <kcri...@gmail.com> wrote:

We (not just Sage, but you and I!) have been discussing this for
almost 15 years.

Haha, true!

 

SageMath has several other long-term contributors who also package
software. We're all roughly on the same page about what it would take
to fix the sage installation for end users.

And some of these people (perhaps kiwifb?) have not been as directly involved in some of the recent disputes.   Maybe there is a path forward (I also presume the CoCC is thinking about this). 

kiwifb has a custom-made Sage on a mini-distro (a Gentoo prefix) which mostly works for him - and he's too busy anyway, I suppose.

 

  

But so far, every attempt to disentangle the
library/distribution to enable this division of labor has been met
with resistance by essentially one person.

Well, more accurately there must be a critical mass of people who, like Kwankyu in some recent comments (apologies for not having link to hand), want to trust that the related process undertaken by that person is worth doing, and to let that proceed.  Otherwise they would have spoken up, as many longer-term developers are not shy of doing so on other matters. 

 

Kwankyu has been very open in saying that he does political voting.

I presume that's what applies to the rest of that "mass" you mention - almost everyone there is a convicted serial macOS user.

Regarding WSL in Dima's post, I thought https://github.com/sagemath/sage/pull/37184 (and the followups) addressed this quite a bit - that was what I was referring to.  If I could get it to work, I think anyone could.  But I didn't try Jupyterlab, maybe that's not included in it.  Anyway, I was definitely not referring to anyone who knows what "apt-get" is in WSL.  So am I right in your saying that Jupyter wouldn't work "out of the box" with Sage with the conda-based solution for WSL?  To me, that's an argument *for* batteries, not against.  

No, no amount of "batteries" will help you here - you need your Jupyter to be run on the Windows side, not on WSL side, so that you can use either a Windows browser or (Windows-side) VS Code to run Jupyter.

What would really simplify things here is creation of a Windows based installer, not mere a document

on dozens of things to be done to set it all up.

 

As to whether it would work with Conda-based Sage in WSL - I don't know, the crucial thing here is automatic discovery of Sage's Jupyter kernel (a small JSON file)

Same applies for the MacOS version provided by 3manifolds, my assumption was that this would work "out of the box" if you do sage -n jupyter or something.

3manifolds app packages a completely separate full-blown Jupyter installation

to interact with Sage (with their standard launcher), and that's the only Jupyter they support.

They don't need to package "batteries" which are just ballast for their app.

 That assumption could be wrong - but again, why put additional barriers to the user?  "Normal" software that "normal" i.e. non-developer people use in the real world doesn't do that.  Why make that a prerequisite for just doing math?  I hate to beat the dead horse of the now-debatable mission statement, but does Mathematica make you separately download and install a notebook?   Even LaTeX has this problem - you have to install the distribution separately from TeXShop or what have you - and just like the developer friction noted here, it's a little bit of extra friction.

> What fragmentation are you talking about? 

I meant that it's a bit silly (from the Mac or Windows perspective) that one even needs Arch, Ubuntu, Debian, Gentoo, Fedora, or anything else

 

Mac? I am not familiar with any medium/large size business which uses macOS on anything apart from desk/laptop.

Windows? WSL didn't arise from nothing...

 

(sorry if I failed to notice irony here)

on the massive (and probably incorrect) list on Wikipedia: https://en.wikipedia.org/wiki/List_of_Linux_distributions  That's a massive duplication of effort right there.

Cf. https://en.wikipedia.org/wiki/List_of_the_largest_Protestant_denominations

(and that's "protestant"+"largest" only)

> It has to be formulated and agreed upon in general lines, otherwise such a summit would be a waste of time.

Agreed.  All of my points are irrelevant compared to getting us back on some consensus track.  That means toning down the rhetoric and candidly saying what sub-optimal concessions might be on the table (to be clear, for everyone).  It's clear now that at least two visions for Sage packaging/modularization which, in their current technical state, are viewed by stakeholders as colliding in their purest forms, but it seems unlikely that Sage is not Turing-complete enough to support a modus vivendi.

--
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+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/7ebdcd4a-b8fa-4e1a-8f65-687730fa309bn%40googlegroups.com.

[Dima Pasechnik]

On Mon, Apr 15, 2024 at 5:41 PM kcrisman <kcri...@gmail.com> wrote:

We (not just Sage, but you and I!) have been discussing this for
almost 15 years.

Haha, true!

 

SageMath has several other long-term contributors who also package
software. We're all roughly on the same page about what it would take
to fix the sage installation for end users.

And some of these people (perhaps kiwifb?) have not been as directly involved in some of the recent disputes.   Maybe there is a path forward (I also presume the CoCC is thinking about this). 

  

But so far, every attempt to disentangle the
library/distribution to enable this division of labor has been met
with resistance by essentially one person.

Well, more accurately there must be a critical mass of people who, like Kwankyu in some recent comments (apologies for not having link to hand), want to trust that the related process undertaken by that person is worth doing, and to let that proceed.  Otherwise they would have spoken up, as many longer-term developers are not shy of doing so on other matters. 

Regarding WSL in Dima's post, I thought https://github.com/sagemath/sage/pull/37184 (and the followups) addressed this quite a bit - that was what I was referring to.  If I could get it to work, I think anyone could.  But I didn't try Jupyterlab, maybe that's not included in it.  Anyway, I was definitely not referring to anyone who knows what "apt-get" is in WSL.  So am I right in your saying that Jupyter wouldn't work "out of the box" with Sage with the conda-based solution for WSL?  To me, that's an argument *for* batteries, not against.  

Same applies for the MacOS version provided by 3manifolds, my assumption was that this would work "out of the box" if you do sage -n jupyter or something.  That assumption could be wrong - but again, why put additional barriers to the user?  "Normal" software that "normal" i.e. non-developer people use in the real world doesn't do that.  Why make that a prerequisite for just doing math?  I hate to beat the dead horse of the now-debatable mission statement, but does Mathematica make you separately download and install a notebook?

scipy does, 

sympy does, 

Macaulay2 does,

GAP does, 

R does, 

Julia does...

 

  Even LaTeX has this problem - you have to install the distribution separately from TeXShop or what have you - and just like the developer friction noted here, it's a little bit of extra friction.

> What fragmentation are you talking about? 

I meant that it's a bit silly (from the Mac or Windows perspective) that one even needs Arch, Ubuntu, Debian, Gentoo, Fedora, or anything else on the massive (and probably incorrect) list on Wikipedia: https://en.wikipedia.org/wiki/List_of_Linux_distributions  That's a massive duplication of effort right there.

> It has to be formulated and agreed upon in general lines, otherwise such a summit would be a waste of time.

Agreed.  All of my points are irrelevant compared to getting us back on some consensus track.  That means toning down the rhetoric and candidly saying what sub-optimal concessions might be on the table (to be clear, for everyone).  It's clear now that at least two visions for Sage packaging/modularization which, in their current technical state, are viewed by stakeholders as colliding in their purest forms, but it seems unlikely that Sage is not Turing-complete enough to support a modus vivendi.

--

[François Bissey]

On 16/04/24 04:41, kcrisman wrote:
> SageMath has several other long-term contributors who also package
> software. We're all roughly on the same page about what it would take
> to fix the sage installation for end users.
>
>
> And some of these people (perhaps kiwifb?) have not been as directly
> involved in some of the recent disputes.   Maybe there is a path forward
> (I also presume the CoCC is thinking about this).

I would say I have involved myself too much already. I am regularly
asked to review some of those tickets that are disputed or become disputed.

It floods my inbox and makes my heart sink.

François

[John H Palmieri]

+1 to the inclusion of the package, in case anyone views the voting as still open.

François, thank you for letting us know about how the ongoing disputes are affecting you. I feel your pain.

Regards,

  John

[Dima Pasechnik]

On 15 April 2024 22:13:59 BST, John H Palmieri <jhpalm...@gmail.com> wrote:
>+1 to the inclusion of the package, in case anyone views the voting as
>still open.
>
>François, thank you for letting us know about how the ongoing disputes are
>affecting you. I feel your pain.

John, do you think Francois is the only one? I oscillate between quitting the project, making a fork, continuing this endless voting fight, etc. - instead of doing more useful things.

I propose to go back to merging PRs etc by consensus, while we figure out a compromise.

Dima

[Dima Pasechnik]

Well, on the latest disputed PR https://github.com/sagemath/sage/pull/37796 I proposed

to stop with this all and go back to getting the PRs approved by consensus.

Should we call an urgent general vote on this?

Dima

François

--
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+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/d7dd2f74-8c1a-4e9a-be42-5b4816065e30%40gmail.com.

[David Roe]

On Mon, Apr 15, 2024 at 5:50 PM Dima Pasechnik <dim...@gmail.com> wrote:

On Mon, Apr 15, 2024 at 10:01 PM François Bissey <frp.b...@gmail.com> wrote:

On 16/04/24 04:41, kcrisman wrote:
>     SageMath has several other long-term contributors who also package
>     software. We're all roughly on the same page about what it would take
>     to fix the sage installation for end users.
>
>
> And some of these people (perhaps kiwifb?) have not been as directly
> involved in some of the recent disputes.   Maybe there is a path forward
> (I also presume the CoCC is thinking about this).

I would say I have involved myself too much already. I am regularly
asked to review some of those tickets that are disputed or become disputed.

It floods my inbox and makes my heart sink.

Well, on the latest disputed PR https://github.com/sagemath/sage/pull/37796 I proposed

to stop with this all and go back to getting the PRs approved by consensus.

Should we call an urgent general vote on this?

I'm happy to discuss whether we should change course on this, but it should be in another thread.

On the original topic, I'm +1 for including python_build.

David

[kcrisman]

It would be fun to continue the conversation with Dima, but clutter things up here too much, as David points out.  Suffice to say that certainly

What would really simplify things here is creation of a Windows based installer, not mere a document

on dozens of things to be done to set it all up.

this would be phenomenal (was the Cygwin installer that existed for a short time a version of this?) and

3manifolds app packages a completely separate full-blown Jupyter installation

to interact with Sage (with their standard launcher), and that's the only Jupyter they support.

They don't need to package "batteries" which are just ballast for their app.

got it and 

on the massive (and probably incorrect) list on Wikipedia: https://en.wikipedia.org/wiki/List_of_Linux_distributions  That's a massive duplication of effort right there.

Cf. https://en.wikipedia.org/wiki/List_of_the_largest_Protestant_denominations

(and that's "protestant"+"largest" only)

you might be surprised I agree that this is a relevant analogy, though perhaps for opposite reasons of yours :-)

[kcrisman]

scipy does, 

sympy does, 

Macaulay2 does,

GAP does, 

R does, 

Julia does...

In this case I do view the comment as related to the actual thread; I consider all of those things as excluding a lot of users, and hence defeating part of the promise of open source software.  As long as open source is "by developers, for developers", it will miss out on that part of the promise, which is unfortunate.  How many actual graphic designers use GIMP? :-(  https://enlyft.com/tech/products/gimp as a more or less random link.

The backend part of the promise, as you noted, is already largely won.  But that's not the place where Sage lives.  I don't really care about kitchen sink or extreme debundling, but I do care about ease of brand-new users starting to use Sage, and then to be won over as developers as their skills improve.  Perhaps that's antediluvian.  Then so be it.

[Dima Pasechnik]

On 16 April 2024 00:47:37 BST, kcrisman <kcri...@gmail.com> wrote:
>
>
>scipy does,
>sympy does,
>Macaulay2 does,
>GAP does,
>R does,
>Julia does...
>
>
>In this case I do view the comment as related to the actual thread; I
>consider all of those things as excluding a lot of users, and hence
>defeating part of the promise of open source software.

No, it is not. You can install Jupyter and launch a notebook without leaving a Python interactive session (if it is run in a venv).
So this can be scripted away, into a Sage command.
Or, indeed, you can do the same from VS Code.

A user who cannot do even this would not be able to use Sage much, anyway.

[Marc Culler]

+1 on making python_build a standard package.

- Marc

[Matthias Koeppe]

An update: https://github.com/sagemath/sage/pull/37300, which implemented what I proposed here, was positively reviewed (thanks, François!) and has been merged in the latest beta, 10.4.beta4.

Many thanks to all who participated in this poll. It's an illustration 

(1) that participation in our community matters, and 

(2) that keeping proper focus in discussions matters.

My work over the years to bring the building and installation of Python packages in the Sage distribution to best practices can now proceed. 

The next step (in preparation since 2022):

- "Use pypa/build instead of pip wheel" (https://github.com/sagemath/sage/pull/35618, needs review)