[sage-devel] Re: Proposal (redo): Make python_build (and its dependency pyproject_hooks) a standard package

[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*) 


On Tuesday, April 9, 2024 at 8:44:36 PM UTC-7 Matthias Koeppe wrote:

> 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. 
>
>

-- 
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/c87dabeb-785f-452c-950b-25371aae5ecfn%40googlegroups.com.

[sage-devel] Re: Proposal (redo): Make python_build (and its dependency pyproject_hooks) a standard package

[Marc Culler]

+1 on making python_build a standard package.

- Marc

On Tuesday, April 9, 2024 at 10:44:36 PM UTC-5 Matthias Koeppe wrote:

> 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. 
>
>

-- 
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/6bb5958c-04a7-4f8f-bf94-79b9dc7139a5n%40googlegroups.com.

Re: [sage-devel] Re: Proposal (redo): Make python_build (and its dependency pyproject_hooks) a standard package

[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 :-)

-- 
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/7a8ce51d-0fff-4360-8fb8-4487ab8f3953n%40googlegroups.com.

Re: [sage-devel] Re: Proposal (redo): Make python_build (and its dependency pyproject_hooks) a standard package

[David Roe]

On Mon, Apr 15, 2024 at 5:50 PM Dima Pasechnik  wrote:

>
>
> On Mon, Apr 15, 2024 at 10:01 PM François Bissey 
> 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

-- 
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/CAChs6_mhaDuY_0VGB5nT0xOUvTeGfdSj8MF%3DFR44fnygtzTiOw%40mail.gmail.com.

Re: [sage-devel] Re: Proposal (redo): Make python_build (and its dependency pyproject_hooks) a standard package

[Dima Pasechnik]

On Mon, Apr 15, 2024 at 10:01 PM François Bissey 
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?

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+unsubscr...@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
> .
>

-- 
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/CAAWYfq0r4vFeD36jhVEBYhxGWebcCZ2_9iKc1J8tdoyJzRBAQw%40mail.gmail.com.

Re: [sage-devel] Re: Proposal (redo): Make python_build (and its dependency pyproject_hooks) a standard package

[Dima Pasechnik]

On 15 April 2024 22:13:59 BST, John H Palmieri  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

>
>Regards,
>  John
>
>
>On Monday, April 15, 2024 at 2:01:43 PM UTC-7 François Bissey 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.
>>
>> 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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/B9B7E1DE-1150-4773-8091-2591A4CC0AB5%40gmail.com.

Re: [sage-devel] Re: Proposal (redo): Make python_build (and its dependency pyproject_hooks) a standard package

[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


On Monday, April 15, 2024 at 2:01:43 PM UTC-7 François Bissey 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.
>
> 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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/94636127-868a-415a-9033-8159582292c6n%40googlegroups.com.

Re: [sage-devel] Re: Proposal (redo): Make python_build (and its dependency pyproject_hooks) a standard package

[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

--
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/d7dd2f74-8c1a-4e9a-be42-5b4816065e30%40gmail.com.

Re: [sage-devel] Re: Proposal (redo): Make python_build (and its dependency pyproject_hooks) a standard package

[Dima Pasechnik]

On Mon, Apr 15, 2024 at 5:41 PM kcrisman  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.
>
> --
> 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/7ebdcd4a-b8fa-4e1a-8f65-687730fa309bn%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/CAAWYfq2ge95V2XtFFtM3gsgyZsgUDZBb0sg%3DcLq%3DRSkqZwj_hg%40mail.gmail.com.

Re: [sage-devel] Re: Proposal (redo): Make python_build (and its dependency pyproject_hooks) a standard package

[Dima Pasechnik]

On Mon, Apr 15, 2024 at 5:41 PM kcrisman  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 

Re: [sage-devel] Re: Proposal (redo): Make python_build (and its dependency pyproject_hooks) a standard package

[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 :-) 

-- 
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/c23c661d-f378-45c8-9bd1-be7eef87f57fn%40googlegroups.com.

Re: [sage-devel] Re: Proposal (redo): Make python_build (and its dependency pyproject_hooks) a standard package

[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.

-- 
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/7ebdcd4a-b8fa-4e1a-8f65-687730fa309bn%40googlegroups.com.

Re: [sage-devel] Re: Proposal (redo): Make python_build (and its dependency pyproject_hooks) a standard package

[Dima Pasechnik]

On Mon, Apr 15, 2024 at 12:21 PM kcrisman  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

-- 
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 

Re: [sage-devel] Re: Proposal (redo): Make python_build (and its dependency pyproject_hooks) a standard package

[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

-- 
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/c88f75df-9ff5-44e6-b6e5-6c8aacb495ban%40googlegroups.com.

Re: [sage-devel] Re: Proposal (redo): Make python_build (and its dependency pyproject_hooks) a standard package

[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.

-- 
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/Zh0XiN1zHQrhfGZN%40stitch.

Re: [sage-devel] Re: Proposal (redo): Make python_build (and its dependency pyproject_hooks) a standard package

[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.

-- 
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/c22329d3-cf4e-4790-80ed-869b32ad61c7n%40googlegroups.com.

Re: [sage-devel] Re: Proposal (redo): Make python_build (and its dependency pyproject_hooks) a standard package

['tobia...@gmx.de' via sage-devel]

-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.

On Monday, April 15, 2024 at 6:27:32 AM UTC+8 Dima Pasechnik wrote:

>
>
> On 14 April 2024 19:14:51 BST, Matthias Koeppe  
> 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
>
> >- "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.
> >
>

-- 
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/fac4c61a-5dbf-4a4d-aa00-09cde96d8d9an%40googlegroups.com.

Re: [sage-devel] Re: Proposal (redo): Make python_build (and its dependency pyproject_hooks) a standard package

[Dima Pasechnik]

On 14 April 2024 19:14:51 BST, Matthias Koeppe  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

>- "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.
>

-- 
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/E6787E1A-38C9-4C92-A2EE-525BDD491631%40gmail.com.

[sage-devel] Re: Proposal (redo): Make python_build (and its dependency pyproject_hooks) a standard package

[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.

-- 
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/948664aa-e468-4c42-95f4-4ded749029f0n%40googlegroups.com.

[sage-devel] Re: Proposal (redo): Make python_build (and its dependency pyproject_hooks) a standard package

[Matthias Koeppe]

Thanks all. 
I consider this approved.

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

On Tuesday, April 9, 2024 at 8:44:36 PM UTC-7 Matthias Koeppe wrote:

> 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. 
>
>

-- 
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/68392bfe-2562-4bbb-9683-97d554e50bafn%40googlegroups.com.

[sage-devel] Re: Proposal (redo): Make python_build (and its dependency pyproject_hooks) a standard package

[Nathan Dunfield]

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

On Tuesday, April 9, 2024 at 10:44:36 PM UTC-5 Matthias Koeppe wrote:

> 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. 
>
>

-- 
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/13f7a510-d4e8-4a64-a037-eb0094845a33n%40googlegroups.com.