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.
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 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.
We (not just Sage, but you and I!) have been discussing this for
almost 15 years.
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.
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.
Pyenv is easier than sage distro, much easier.
Well, depending on a legacy (3.9) Python version isn't the problem for the most, I hope. :-)
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+...@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.
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.
--
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.
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 proposedto stop with this all and go back to getting the PRs approved by consensus.Should we call an urgent general vote on this?
What would really simplify things here is creation of a Windows based installer, not mere a documenton dozens of things to be done to set it all up.
3manifolds app packages a completely separate full-blown Jupyter installationto 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.
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.(and that's "protestant"+"largest" only)
scipy does,sympy does,Macaulay2 does,GAP does,R does,Julia does...