On Mon, Apr 15, 2024 at 12:21 PM kcrisman <kcris...@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 -- 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/CAAWYfq1cxY-fBx8-MHO48z8U32S%3DLA8KoHxnMZpXWzobq4mYGg%40mail.gmail.com.
