Re: [sage-devel] Re: What was/is/will be the purpose of maintaining the Sage distribution?
On Thursday, April 27, 2023 at 2:54:47 PM UTC-7 Isuru Fernando wrote: On Thu, Apr 27, 2023 at 1:00 PM Michael Orlitzky wrote: [...] Gentoo Prefix [...] Nix [...] Guix and spack could also work. I guess there are several requirements we need 1. Support for all major OS/architecture combinations 2. Easy to build for rare OS/architecture combinations 3. Possible to install as a non-root user 4. Binaries are available for non-root AFAIK, there's no package manager that has all 4 above and we will have to pick which requirements are more important than others. I believe 1/3/4 are the most important and conda-forge suppports them. And there's also the very important: 5. Its relevance in the Python dev world. ... where conda-forge is the only choice (other than PyPI). -- 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/5250d893-13e1-440c-bcda-ccb2dadf653dn%40googlegroups.com.
Re: [sage-devel] Re: What was/is/will be the purpose of maintaining the Sage distribution?
On Thu, Apr 27, 2023 at 1:00 PM Michael Orlitzky wrote: > On Thu, 2023-04-27 at 05:49 -0700, William Stein wrote: > > Hi, > > > > To what extent does or could Conda with a little more work solve most > > of these problems? There are some notes below from me poking around, > > and I'm very optimistic. > > This isn't the first time the idea has come up. Burcin got pretty far > with it using Gentoo Prefix in place of Conda: > > https://groups.google.com/g/sage-devel/c/XFJn3jGVBG8 > > Nix could also work. All three serve roughly the same purpose. > True. Guix and spack could also work. I guess there are several requirements we need 1. Support for all major OS/architecture combinations 2. Easy to build for rare OS/architecture combinations 3. Possible to install as a non-root user 4. Binaries are available for non-root AFAIK, there's no package manager that has all 4 above and we will have to pick which requirements are more important than others. Isuru > > -- > 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/0a85f27c909f8d8f185801af2228e6331bcad544.camel%40orlitzky.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/CA%2B01voM16Tms1A2R2%3DQ2DW13ZzJ7CNUnMPBucny7jrsyJc0hiA%40mail.gmail.com.
[sage-devel] Re: What was/is/will be the purpose of maintaining the Sage distribution?
On Thursday, April 27, 2023 at 5:12:45 AM UTC-7 kcrisman wrote: As an example, how old of a Windows computer could one install the current Sage on? I mean from scratch - not necessarily from source - using WSL, which I guess is now the main supported way to do so? One needs Windows >= 10 and a CPU with the necessary virtualization support. What about the Cygwin installer - does it still exist in older versions on sagemath.org mirrors, what does that support? How easy is it for someone who does NOT know about compiling to install Sage on a not-too-recent Windows machine? It's dead. One thing that might help all of this is having older versions of Sage *binaries* for such platforms readily available for download (as many of our upstream packages in fact do). I don't think we are. We decided to get out of the business to publish binaries; we weren't doing it well, and numerous distributions and third-party binaries filled the role. -- 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/f0a5e81c-ca36-4941-9f18-e6a53a168d9an%40googlegroups.com.
Re: [sage-devel] Re: What was/is/will be the purpose of maintaining the Sage distribution?
On Thu, Apr 27, 2023 at 1:21 PM Matthias Koeppe wrote: > > On Thursday, April 27, 2023 at 5:49:50 AM UTC-7 William Stein wrote: > > To what extent does or could Conda with a little more work solve most > of these problems? [...] > I also think this section > https://doc.sagemath.org/html/en/installation/conda.html#using-conda-to-provide-all-dependencies-for-the-sage-library-experimental > called "Using conda to provide all dependencies for the Sage library > (experimental)" is pretty exciting! > > > Yes, I think this mode of installation should be the future default of Sage > for developers. AWESOME and thanks for the clarification! I'm strongly supportive of this, and I agree that switching to GitHub from Trac was a good model for how to approach this problem. -- William > > In any case, I think that migrating from "Sage the distribution" to > solving a lot of the misc environment issues > via conda would be very analogous to switching to Github, instead of > maintaining our own issue tracker. > > > Indeed, and just like in our successful transition to GitHub, a clean planned > switchover to the new model is the most effective solution. > > Attempts to do this gradually (such as the attempt of a soft transition from > Trac to GitLab by means of maintaining a Trac<->GitLab gateway) fail because > of the concave costs on the path from one end to the other. > > So, as I said, I would welcome a clear decision by the community to do so -- > with a target date or target release number. > > > -- > 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/26656418-5f72-4330-bb6c-dd4c968de928n%40googlegroups.com. -- William (http://wstein.org) -- 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/CACLE5GAwbFkfZAm0NQcbPb5oDE0vv3Nzj9URF%3Dd9J9MUWe0wwQ%40mail.gmail.com.
Re: [sage-devel] Re: What was/is/will be the purpose of maintaining the Sage distribution?
On Thursday, April 27, 2023 at 10:07:44 AM UTC-7 Isuru Fernando wrote: > and took 5.8GB disk instead of the 3GB disk of the Sage mac app). Yes, conda packages usually come with batteries included which means packages come with their optional build time dependencies installed. That's usually not a big deal for other packages, but Sage is special in that it has tons of dependencies. I haven't checked the details for conda, but from what I see on some distros, I think there are a few particular packages that cause this: - our use of libgd (see https://github.com/sagemath/sage/pull/35477) that pulls in a huge set of (unused) graphics libraries - our use of CAS packages that are not separable from their GUI components (in particular GIAC) -- 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/9c9e10d1-60c6-42b7-b0d7-77d7f0ebbf74n%40googlegroups.com.
Re: [sage-devel] Re: What was/is/will be the purpose of maintaining the Sage distribution?
On Thursday, April 27, 2023 at 5:49:50 AM UTC-7 William Stein wrote: To what extent does or could Conda with a little more work solve most of these problems? [...] I also think this section https://doc.sagemath.org/html/en/installation/conda.html#using-conda-to-provide-all-dependencies-for-the-sage-library-experimental called "Using conda to provide all dependencies for the Sage library (experimental)" is pretty exciting! Yes, I think this mode of installation should be the future default of Sage for developers. In any case, I think that migrating from "Sage the distribution" to solving a lot of the misc environment issues via conda would be very analogous to switching to Github, instead of maintaining our own issue tracker. Indeed, and just like in our successful transition to GitHub, a clean planned switchover to the new model is the most effective solution. Attempts to do this gradually (such as the attempt of a soft transition from Trac to GitLab by means of maintaining a Trac<->GitLab gateway) fail because of the concave costs on the path from one end to the other. So, as I said, I would welcome a clear decision by the community to do so -- with a target date or target release number. -- 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/26656418-5f72-4330-bb6c-dd4c968de928n%40googlegroups.com.
Re: [sage-devel] Re: [sage-release] Sage 10.0.rc0 released
On Thursday, April 27, 2023 at 3:59:22 AM UTC-7 Michael Orlitzky wrote: On 2023-04-26 19:59:01, Matthias Koeppe wrote: > Just as a data point, eliminating the spkg and only supporting system PARI > 2.15.x would have the effect to eliminate support of: > - all versions of Ubuntu except for 23.04 (lunar); > - all openSUSE Leap versions, leaving only the rolling distro (Tumbleweed). > Source: https://repology.org/project/pari/versions It would be better if we could support the last minor version of PARI as well, but I'm not volunteering anyone else's time to do it. If we adopt a more flexible approach in sagelib, we'll sometimes get lucky: there just won't be any breakage between minor versions, or it will be trivial to support both. But yes, there will eventually be some change that forces us to say "upgrade your PARI, or use an older version of sage." It's not the end of the world if users on a distro with old dependencies have to stick to an older version of sage. Ideally, they would be getting sage from their distro in the first place. A problem only arises when you try to build a bleeding-edge sage on an older stable distro -- an undertaking unsupported by most projects. Is it? I would say that Sage is very special in this regard because of its extreme number of complicated dependencies; and because of its long-standing goals of empowering the members of the user community to become contributors. For example, people can contribute to sympy, numpy, scipy etc. on a very wide range of systems (pretty much the same that we currently support in the Sage distribution because we recently tightened our compiler requirements based on scipy's needs). And we know that development against an old version of Sage is not practical; we always recommend to people to start from the latest beta for development. But this creates a serious barrier: If Sage development can only be done on bleeding-edge distributions, new Sage developers need to abandon their current distribution. That's really bad. Anyone bothered by this can of course send us patches that extend compatibility to older PARI. Would we welcome such patches? When we upgrade a package such as PARI, typically very experienced Sage developers have already assessed how easy it would be to keep the old version supported. When it is decided to drop support, it is often not because we don't know how to support both but rather because we do not want to have more complicated code in Sage. -- 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/9b1b17b2-9234-4cfb-82b8-8d9ab61ef457n%40googlegroups.com.
Re: [sage-devel] Re: What was/is/will be the purpose of maintaining the Sage distribution?
On Thu, 2023-04-27 at 05:49 -0700, William Stein wrote: > Hi, > > To what extent does or could Conda with a little more work solve most > of these problems? There are some notes below from me poking around, > and I'm very optimistic. This isn't the first time the idea has come up. Burcin got pretty far with it using Gentoo Prefix in place of Conda: https://groups.google.com/g/sage-devel/c/XFJn3jGVBG8 Nix could also work. All three serve roughly the same purpose. -- 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/0a85f27c909f8d8f185801af2228e6331bcad544.camel%40orlitzky.com.
Re: [sage-devel] Re: What was/is/will be the purpose of maintaining the Sage distribution?
Isuru, Thanks for answering all my questions. I just want to reiterate that I'm thrilled with what you are doing and greatly appreciate it! William On Thu, Apr 27, 2023 at 10:07 AM Isuru Fernando wrote: > > > it fails with "└─ sage is uninstallable because there are no viable > > options" > > We don't have a python 3.11 version of sage in conda yet. I started a PR > manually as the automatic update > failed for some reason. > > > What is it doing that first time, and why is it silent? It's very > > unnerving. > > macOS 10.15+ does some shady things when users request to run "untrusted" > applications. For eg: > > % clang hello.c > % time ./a.out > Hello world! > ./a.out 0.00s user 0.00s system 0% cpu 0.380 total > % time ./a.out > Hello world! > ./a.out 0.00s user 0.00s system 62% cpu 0.006 total > > See https://lapcatsoftware.com/articles/catalina-executables.html for a > possible explanation. > Sage loads hundreds of dynamic libraries not all at the same time, so macOS > sends multiple requests > to Apple servers. > > > and took 5.8GB disk instead of the 3GB disk of the Sage mac app). > > Yes, conda packages usually come with batteries included which means packages > come with their > optional build time dependencies installed. That's usually not a big deal for > other packages, but > Sage is special in that it has tons of dependencies. > > As usual, the biggest hurdle to making things work more seamlessly is > manpower. > Most of the niche packages that sage depends on are maintained by me and > Julian and improvements > to supporting conda in the sage build system are mostly Matthias and Tobias. > > Isuru > > > > On Thu, Apr 27, 2023 at 7:49 AM William Stein wrote: >> >> Hi, >> >> To what extent does or could Conda with a little more work solve most >> of these problems? There are some notes below from me poking around, >> and I'm very optimistic. >> >> I looked at >> >> https://doc.sagemath.org/html/en/installation/conda.html >> >> and I would love some further discussion of that and whether with >> enough help it could be viable. >> For example, on my M1 mac I just tried what seems to me to be the most >> obvious first thing to do >> based on the instructions: >> >> (base) wstein@max ~ % mamba create -n sage sage python=3.11 >> >> and it fails with "└─ sage is uninstallable because there are no >> viable options" >> Obviously I'm going to nex try "mamba create -n sage sage", which works, but >> that's not what our docs say to do. Incidentally, it took about a >> minute to download >> and install everything (and took 5.8GB disk instead of the 3GB disk of >> the Sage mac app). >> Then a few minutes of me being confused if I should do >> "mamba activate sage" or "conda activate sage", and finally I typed "sage" >> and >> strangely it just shows nothing at all while it mysteriously takes >> about a minute >> for sage to start the first time (on my M1 max laptop with SSD). Sage then >> starts and works fine. Subsequent sage startups are very fast (e.g., 1 >> second). >> What is it doing that first time, and why is it silent? It's very unnerving. >> >> I also think this section >> https://doc.sagemath.org/html/en/installation/conda.html#using-conda-to-provide-all-dependencies-for-the-sage-library-experimental >> called "Using conda to provide all dependencies for the Sage library >> (experimental)" is pretty exciting! >> >> For many years when I gave talks about Sage, I had a slide: "What is >> Sage", with two points: >> >> 1. A distribution of open source math software >> 2. A new library tying everything together >> >> I definitely only started 1 out of necessity because nothing existed >> at the time. My hope is that >> at this point in time conda is good enough that maybe it could totally >> solve 1, and we can focus on 2? >> >> In any case, I think that migrating from "Sage the distribution" to >> solving a lot of the misc environment issues >> via conda would be very analogous to switching to Github, instead of >> maintaining our own issue tracker. >> I.e., if you want the latest version of sage on Ubuntu 22.04 (say), >> then our recommendation is "use conda", >> and we put effort into making Sage-via-conda extremely good. If you >> want some random version of sage, >> then you can use system packages. >> >> For CoCalc.com, the key thing we need is a way to have self-contained >> stable installations of sage-9.1, 9.2, 9.3, 9.4, 9.5, 9.6, 9.7, 9.8, >> 10.0, etc. all on the same Ubuntu system, all at once, and have them >> not get screwed up when we do normal system updates. Doing major >> Ubuntu version updates (e.g., 20.04 --> 22.04) doesn't have to be >> supported. >> My impression is that conda potentially solves this problem at least >> as well as sage-the-distribution does right now. >> >> -- William >> >> PS Thanks again to the people who put so much work into packaging sage >> and its dependencies for conda! >> >> On Thu, Apr 27, 2023 at 5:12 AM kcrisman wrote:
Re: [sage-devel] Re: What was/is/will be the purpose of maintaining the Sage distribution?
> it fails with "└─ sage is uninstallable because there are no viable options" We don't have a python 3.11 version of sage in conda yet. I started a PR manually as the automatic update failed for some reason. > What is it doing that first time, and why is it silent? It's very unnerving. macOS 10.15+ does some shady things when users request to run "untrusted" applications. For eg: % clang hello.c % time ./a.out Hello world! ./a.out 0.00s user 0.00s system 0% cpu 0.380 total % time ./a.out Hello world! ./a.out 0.00s user 0.00s system 62% cpu 0.006 total See https://lapcatsoftware.com/articles/catalina-executables.html for a possible explanation. Sage loads hundreds of dynamic libraries not all at the same time, so macOS sends multiple requests to Apple servers. > and took 5.8GB disk instead of the 3GB disk of the Sage mac app). Yes, conda packages usually come with batteries included which means packages come with their optional build time dependencies installed. That's usually not a big deal for other packages, but Sage is special in that it has tons of dependencies. As usual, the biggest hurdle to making things work more seamlessly is manpower. Most of the niche packages that sage depends on are maintained by me and Julian and improvements to supporting conda in the sage build system are mostly Matthias and Tobias. Isuru On Thu, Apr 27, 2023 at 7:49 AM William Stein wrote: > Hi, > > To what extent does or could Conda with a little more work solve most > of these problems? There are some notes below from me poking around, > and I'm very optimistic. > > I looked at > > https://doc.sagemath.org/html/en/installation/conda.html > > and I would love some further discussion of that and whether with > enough help it could be viable. > For example, on my M1 mac I just tried what seems to me to be the most > obvious first thing to do > based on the instructions: > > (base) wstein@max ~ % mamba create -n sage sage python=3.11 > > and it fails with "└─ sage is uninstallable because there are no > viable options" > Obviously I'm going to nex try "mamba create -n sage sage", which works, > but > that's not what our docs say to do. Incidentally, it took about a > minute to download > and install everything (and took 5.8GB disk instead of the 3GB disk of > the Sage mac app). > Then a few minutes of me being confused if I should do > "mamba activate sage" or "conda activate sage", and finally I typed "sage" > and > strangely it just shows nothing at all while it mysteriously takes > about a minute > for sage to start the first time (on my M1 max laptop with SSD). Sage then > starts and works fine. Subsequent sage startups are very fast (e.g., 1 > second). > What is it doing that first time, and why is it silent? It's very > unnerving. > > I also think this section > > https://doc.sagemath.org/html/en/installation/conda.html#using-conda-to-provide-all-dependencies-for-the-sage-library-experimental > called "Using conda to provide all dependencies for the Sage library > (experimental)" is pretty exciting! > > For many years when I gave talks about Sage, I had a slide: "What is > Sage", with two points: > > 1. A distribution of open source math software > 2. A new library tying everything together > > I definitely only started 1 out of necessity because nothing existed > at the time. My hope is that > at this point in time conda is good enough that maybe it could totally > solve 1, and we can focus on 2? > > In any case, I think that migrating from "Sage the distribution" to > solving a lot of the misc environment issues > via conda would be very analogous to switching to Github, instead of > maintaining our own issue tracker. > I.e., if you want the latest version of sage on Ubuntu 22.04 (say), > then our recommendation is "use conda", > and we put effort into making Sage-via-conda extremely good. If you > want some random version of sage, > then you can use system packages. > > For CoCalc.com, the key thing we need is a way to have self-contained > stable installations of sage-9.1, 9.2, 9.3, 9.4, 9.5, 9.6, 9.7, 9.8, > 10.0, etc. all on the same Ubuntu system, all at once, and have them > not get screwed up when we do normal system updates. Doing major > Ubuntu version updates (e.g., 20.04 --> 22.04) doesn't have to be > supported. > My impression is that conda potentially solves this problem at least > as well as sage-the-distribution does right now. > > -- William > > PS Thanks again to the people who put so much work into packaging sage > and its dependencies for conda! > > On Thu, Apr 27, 2023 at 5:12 AM kcrisman wrote: > > > > > > As of today, it is plausible that such situations still exist. > > > > > > I am wondering about such situations existing in less-resourced areas > globally (which would include less-resourced parts of developed > countries). One big advantage of Sage-the-distribution historically was > the ability to make USB drives that had the complete thing (maybe also a > Li
Re: [sage-devel] Re: [sage-release] Sage 10.0.rc0 released
On Thu, 2023-04-27 at 08:38 -0700, Nils Bruin wrote: > > But another problem before was that the different packages would not > develop in lockstep. Some components might need one specific version of > prerequisites and others another. So one could run into genuine version > conflicts. In theory this is a problem with every package. But in practice, we've got 20,000 of them and few major conflicts. Solving this is what a linux distribution does, and it's OK to punt the problem to them. Personally I'm not getting out of any work here, since I'm also working on the distro packages. Making Sage more lenient would however be a valuable use of my time, in contrast with the current approach. -- 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/ef9b21e64fcfe5db98b4b438e282170443b097f2.camel%40orlitzky.com.
Re: [sage-devel] Re: [sage-release] Sage 10.0.rc0 released
On Thursday, 27 April 2023 at 03:59:22 UTC-7 Michael Orlitzky wrote: It's not the end of the world if users on a distro with old dependencies have to stick to an older version of sage. Ideally, they would be getting sage from their distro in the first place. A problem only arises when you try to build a bleeding-edge sage on an older stable distro -- an undertaking unsupported by most projects. Anyone bothered by this can of course send us patches that extend compatibility to older PARI. The burden of universal support would however be transferred from the sage developers to the distros where it rightfully lies. It may be that the situation about packaging math software has genuinely improved; in which case this likely thanks to sage: it took a whole bunch of math software, made it so that it could build in a coherently working whole, raised the profile to such a level that people with good connections to distributions stood up willing to support it as package distributions. But another problem before was that the different packages would not develop in lockstep. Some components might need one specific version of prerequisites and others another. So one could run into genuine version conflicts. Sagemath was in a position to then resolve to conflict in the best way *for sage*. It's not clear to me that distributions, that have to serve other interests as well, will be able to do the same. It's also not entirely clear to me that distribution maintainers will always be able to catch erroneous behaviour due to mismatched components. So that's where sage-the-distribution still serves as an insurance policy -- something to fall back on when the version requirements make it impossible to run a set of packages together on a system-wide distribution. it may be an option to provide a reference VM/docker image rather than a "sage-the-distribution" if that is easier to maintain, but at the moment, since we're not providing that, it would be more work. -- 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/1a5e37ce-b740-49a1-a7cb-43995c779c18n%40googlegroups.com.
Re: [sage-devel] Re: What was/is/will be the purpose of maintaining the Sage distribution?
On Thu, 2023-04-27 at 05:12 -0700, kcrisman wrote: > > As an example, how old of a Windows computer could one install the current > Sage on? ... > > In any case, it would be very helpful for people who may be actively using > Sge in less-resourced environment to chime in here. > My desktop is 19 years old and my laptop is now 15. Switching between branches can cause 20 hours of recompile time. If I'm lucky and don't need to use the result, I can cut that in half with -O0. If this were spent doing something useful, it would be more tolerable, but it's spent fetching, compiling, and installing packages that are already on my system. The test suite can take another full day to run -- some of that is useful, but a lot is not. This is the biggest impediment to the use and development of sage on an old system. Upgrading (say) OpenSSL on the system is a sunk cost because it happens anyway. The only question is whether or not I *also* have to repeatedly rebuild some highly specific version that sage wants. The problem is not only the SPKGs, but the way sagelib is designed around them; eliminating the sage distribution would force us to address those indirect inefficiencies in addition to immediately eliminating the direct ones. (I'm planning upgrades in the next year or two, but it will be to relatively low power RISC-V hardware. There are moral, legal, environmental, and other non-financial reasons why people use "old" hardware. But of course the financial reasons are very real too.) -- 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/592557b3cb7efaa5bac7f0cec8781c11ad093a17.camel%40orlitzky.com.
Re: [sage-devel] Re: What was/is/will be the purpose of maintaining the Sage distribution?
Hi, To what extent does or could Conda with a little more work solve most of these problems? There are some notes below from me poking around, and I'm very optimistic. I looked at https://doc.sagemath.org/html/en/installation/conda.html and I would love some further discussion of that and whether with enough help it could be viable. For example, on my M1 mac I just tried what seems to me to be the most obvious first thing to do based on the instructions: (base) wstein@max ~ % mamba create -n sage sage python=3.11 and it fails with "└─ sage is uninstallable because there are no viable options" Obviously I'm going to nex try "mamba create -n sage sage", which works, but that's not what our docs say to do. Incidentally, it took about a minute to download and install everything (and took 5.8GB disk instead of the 3GB disk of the Sage mac app). Then a few minutes of me being confused if I should do "mamba activate sage" or "conda activate sage", and finally I typed "sage" and strangely it just shows nothing at all while it mysteriously takes about a minute for sage to start the first time (on my M1 max laptop with SSD). Sage then starts and works fine. Subsequent sage startups are very fast (e.g., 1 second). What is it doing that first time, and why is it silent? It's very unnerving. I also think this section https://doc.sagemath.org/html/en/installation/conda.html#using-conda-to-provide-all-dependencies-for-the-sage-library-experimental called "Using conda to provide all dependencies for the Sage library (experimental)" is pretty exciting! For many years when I gave talks about Sage, I had a slide: "What is Sage", with two points: 1. A distribution of open source math software 2. A new library tying everything together I definitely only started 1 out of necessity because nothing existed at the time. My hope is that at this point in time conda is good enough that maybe it could totally solve 1, and we can focus on 2? In any case, I think that migrating from "Sage the distribution" to solving a lot of the misc environment issues via conda would be very analogous to switching to Github, instead of maintaining our own issue tracker. I.e., if you want the latest version of sage on Ubuntu 22.04 (say), then our recommendation is "use conda", and we put effort into making Sage-via-conda extremely good. If you want some random version of sage, then you can use system packages. For CoCalc.com, the key thing we need is a way to have self-contained stable installations of sage-9.1, 9.2, 9.3, 9.4, 9.5, 9.6, 9.7, 9.8, 10.0, etc. all on the same Ubuntu system, all at once, and have them not get screwed up when we do normal system updates. Doing major Ubuntu version updates (e.g., 20.04 --> 22.04) doesn't have to be supported. My impression is that conda potentially solves this problem at least as well as sage-the-distribution does right now. -- William PS Thanks again to the people who put so much work into packaging sage and its dependencies for conda! On Thu, Apr 27, 2023 at 5:12 AM kcrisman wrote: > > > As of today, it is plausible that such situations still exist. > > > I am wondering about such situations existing in less-resourced areas > globally (which would include less-resourced parts of developed countries). > One big advantage of Sage-the-distribution historically was the ability to > make USB drives that had the complete thing (maybe also a Linux VM?) on them, > from which one could boot. > > It strikes me that many arguments for removing the distribution along these > lines (not the developer side, which is also important) are akin to those > arguments which assume one should "just" use a remote option for Sage at all > times. Yes, that has been seriously made on multiple occasions, though > usually not on this list. But even "post-pandemic" there are still plenty of > reliable high-speed internet deserts even where I live on the US East Coast, > much less around the world. I wouldn't want to use CoCalc without a fairly > new computer. > > Likewise, there are plenty of people using 5-10 year old computers who, in > principle, could be afforded Sage access, but for our continued upgrading. > (Again, see below for the developer side.) Arguments about how they should > upgrade or face security issues are fine, but in practice (whether for > financial or other reasons) this is not how humans respond to those > incentives, and presumably at least some of them might benefit from Sage. A > lot of the paradigm discussed on this list (but not all, for sure) focuses SO > MUCH on people who have access to fairly recent technology, and that simply > doesn't obtain. > > As an example, how old of a Windows computer could one install the current > Sage on? I mean from scratch - not necessarily from source - using WSL, > which I guess is now the main supported way to do so? What about the Cygwin > installer - does it still exist in older versions on sagemath.org mirrors,
[sage-devel] Re: What was/is/will be the purpose of maintaining the Sage distribution?
As of today, it is plausible that such situations still exist. I am wondering about such situations existing in less-resourced areas globally (which would include less-resourced parts of developed countries). One big advantage of Sage-the-distribution historically was the ability to make USB drives that had the complete thing (maybe also a Linux VM?) on them, from which one could boot. It strikes me that many arguments for removing the distribution along these lines (not the developer side, which is also important) are akin to those arguments which assume one should "just" use a remote option for Sage at all times. Yes, that has been seriously made on multiple occasions, though usually not on this list. But even "post-pandemic" there are still plenty of reliable high-speed internet deserts even where I live on the US East Coast, much less around the world. I wouldn't want to use CoCalc without a fairly new computer. Likewise, there are plenty of people using 5-10 year old computers who, in principle, could be afforded Sage access, but for our continued upgrading. (Again, see below for the developer side.) Arguments about how they should upgrade or face security issues are fine, but in practice (whether for financial or other reasons) this is not how humans respond to those incentives, and presumably at least some of them might benefit from Sage. A lot of the paradigm discussed on this list (but not all, for sure) focuses SO MUCH on people who have access to fairly recent technology, and that simply doesn't obtain. As an example, how old of a Windows computer could one install the current Sage on? I mean from scratch - not necessarily from source - using WSL, which I guess is now the main supported way to do so? What about the Cygwin installer - does it still exist in older versions on sagemath.org mirrors, what does that support? How easy is it for someone who does NOT know about compiling to install Sage on a not-too-recent Windows machine? I bet it's easy to install the various M's ... In any case, it would be very helpful for people who may be actively using Sage in less-resourced environment to chime in here. Moving to the developer side: a) If a critical bug is discovered, we can patch it and don't have to rely on people and infrastructure "outside the project" to fix things for us. Of course, we have been very lucky that packagers for many distributions have been consistently highly engaged with the project; but this is not something that we can take for granted. This is basically why William started Sage in the first place. (Well, one reason!) When I still had time to be an active developer, this was a major source of necessary work. It's true that a lot of packages are now more responsive (or have been canned/subsumed into Sage), but presumably it could still be a problem, especially with some extremely math-specific packages that might not regularly update in a platform-agnostic way. That said, presumably Python and gcc are no longer in the situation where we need to actively maintain a lot of patches to them. b) And, of course, more Sage developers can become contributors to the packaging communities; but there is the real danger that taking care of both upstream development *and* downstream packaging for the same project can lead to developer burnout. This (whether connected to upstream packaging or not) is really the most powerful argument for radical decoupling. (Similarly to the GH transition.) Clearly R fell in this category. Reading the other thread did not really clarify for me whether python3 or gcc fell into this category, and I don't think it will be helpful to revisit that right now. In any case, this should be weighed against Sage ease of access. One thing that might help all of this is having older versions of Sage *binaries* for such platforms readily available for download (as many of our upstream packages in fact do). I don't think we are. In fact, https://www.sagemath.org/mirrors.html was kind of scary - a lot of mirrors don't seem to have anything at all. I will assume I missed a thread (quite likely that I did) that we were dropping binary support via mirrors completely, which needless to say would make my suggestion difficult to implement. I do think it is the best way to provide quite fully-featured versions of Sage to people with less-modern setups (who probably now simply don't use Sage because they can't, or stick with older versions they already have, which we see from time to time on the support list) while still allowing for dropping some of this support when it sucks up too much developer effort. -- 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://gro
Re: [sage-devel] Re: [sage-release] Sage 10.0.rc0 released
On 2023-04-26 19:59:01, Matthias Koeppe wrote: > On Wednesday, April 26, 2023 at 7:37:17 PM UTC-7 Michael Orlitzky wrote: > > Just as a data point, eliminating the spkg and only supporting system PARI > 2.15.x would have the effect to eliminate support of: > - all versions of Ubuntu except for 23.04 (lunar); > - all openSUSE Leap versions, leaving only the rolling distro (Tumbleweed). > Source: https://repology.org/project/pari/versions It would be better if we could support the last minor version of PARI as well, but I'm not volunteering anyone else's time to do it. If we adopt a more flexible approach in sagelib, we'll sometimes get lucky: there just won't be any breakage between minor versions, or it will be trivial to support both. But yes, there will eventually be some change that forces us to say "upgrade your PARI, or use an older version of sage." It's not the end of the world if users on a distro with old dependencies have to stick to an older version of sage. Ideally, they would be getting sage from their distro in the first place. A problem only arises when you try to build a bleeding-edge sage on an older stable distro -- an undertaking unsupported by most projects. Anyone bothered by this can of course send us patches that extend compatibility to older PARI. The burden of universal support would however be transferred from the sage developers to the distros where it rightfully lies. > All this sounds very reasonable, of course. > > A problem that remains is how we would manage user expectations when they > report a bug to us that turns out to be an upstream bug in a package that > we no longer carry as an spkg: We would no longer be able to say "it's > fixed in Sage 10.7" but instead would have to say "not the fault of Sage; > just go upgrade your Linux distro to the unstable release / ask your distro > to backport the bugfix / compile the package yourself from source". That exact response is standard. It's a bit less friendly but a lot more sensible. -- 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/ZEpVhx-yoz9piJF3%40stitch.
Re: [sage-devel] What is the status of sympy in sagemath? In particular the integrator.
I fully agree.
https://github.com/sagemath/sage/issues/34420
https://github.com/sagemath/sage/issues/32133
https://github.com/sagemath/sage/issues/32143
On Thursday, 27 April 2023 at 11:12:31 UTC+2 Oscar Benjamin wrote:
> On Thu, 27 Apr 2023 at 06:25, 'Martin R' via sage-devel
> wrote:
> >
> > On Wednesday, 26 April 2023 at 21:06:30 UTC+2 Oscar Benjamin wrote:
> >>
> >> One thing Sage could do with SymPy's RootSum is to call doit which
> >> will expand using radical formulae if possible:
> >>
> >> x**2/(3*a**2 + 3*a*b*x**3) + RootSum(729*_t**3*a**4*b**2 + 1,
> >> Lambda(_t, _t*log(81*_t**2*a**3*b + x)))
> >>
> >> In [37]: x, a, b, _t = symbols('x, a, b, _t')
> >>
> >> In [38]: expr = x**2/(3*a**2 + 3*a*b*x**3) +
> >> RootSum(Poly(729*_t**3*a**4*b**2 + 1, _t), Lambda(_t,
> >> _t*log(81*_t**2*a**3*b + x)))
> >>
> >> In [39]: print(expr)
> >> x**2/(3*a**2 + 3*a*b*x**3) + RootSum(729*_t**3*a**4*b**2 + 1,
> >> Lambda(_t, _t*log(81*_t**2*a**3*b + x)))
> >>
> >> In [40]: print(expr.doit())
> >> x**2/(3*a**2 + 3*a*b*x**3) +
> >> (-1/(a**4*b**2))**(1/3)*log(a**3*b*(-1/(a**4*b**2))**(2/3) + x)/9 +
> >> (-(-1/(a**4*b**2))**(1/3)/18 -
> >>
> sqrt(3)*I*(-1/(a**4*b**2))**(1/3)/18)*log(81*a**3*b*(-(-1/(a**4*b**2))**(1/3)/18
> >> - sqrt(3)*I*(-1/(a**4*b**2))**(1/3)/18)**2 + x) +
> >> (-(-1/(a**4*b**2))**(1/3)/18 +
> >>
> sqrt(3)*I*(-1/(a**4*b**2))**(1/3)/18)*log(81*a**3*b*(-(-1/(a**4*b**2))**(1/3)/18
> >> + sqrt(3)*I*(-1/(a**4*b**2))**(1/3)/18)**2 + x)
> >
> > If I recall correctly, this is what I did for the FriCAS interface. It
> would be nice to factor out any common functionality, if possible.
>
> Obviously though the RootSum is better than the radicals which is why
> it is used in the first place so the ideal solution would be to
> preserve the RootSum. The simple case above already shows that it is
> better but in others the radical formulae can explode and in more
> complicated cases formulae won't even exist.
>
> --
> Oscar
>
--
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/ac65c5c1-7626-48b6-901e-8a896eddef8an%40googlegroups.com.
Re: [sage-devel] What is the status of sympy in sagemath? In particular the integrator.
On Thu, 27 Apr 2023 at 06:25, 'Martin R' via sage-devel
wrote:
>
> On Wednesday, 26 April 2023 at 21:06:30 UTC+2 Oscar Benjamin wrote:
>>
>> One thing Sage could do with SymPy's RootSum is to call doit which
>> will expand using radical formulae if possible:
>>
>> x**2/(3*a**2 + 3*a*b*x**3) + RootSum(729*_t**3*a**4*b**2 + 1,
>> Lambda(_t, _t*log(81*_t**2*a**3*b + x)))
>>
>> In [37]: x, a, b, _t = symbols('x, a, b, _t')
>>
>> In [38]: expr = x**2/(3*a**2 + 3*a*b*x**3) +
>> RootSum(Poly(729*_t**3*a**4*b**2 + 1, _t), Lambda(_t,
>> _t*log(81*_t**2*a**3*b + x)))
>>
>> In [39]: print(expr)
>> x**2/(3*a**2 + 3*a*b*x**3) + RootSum(729*_t**3*a**4*b**2 + 1,
>> Lambda(_t, _t*log(81*_t**2*a**3*b + x)))
>>
>> In [40]: print(expr.doit())
>> x**2/(3*a**2 + 3*a*b*x**3) +
>> (-1/(a**4*b**2))**(1/3)*log(a**3*b*(-1/(a**4*b**2))**(2/3) + x)/9 +
>> (-(-1/(a**4*b**2))**(1/3)/18 -
>> sqrt(3)*I*(-1/(a**4*b**2))**(1/3)/18)*log(81*a**3*b*(-(-1/(a**4*b**2))**(1/3)/18
>> - sqrt(3)*I*(-1/(a**4*b**2))**(1/3)/18)**2 + x) +
>> (-(-1/(a**4*b**2))**(1/3)/18 +
>> sqrt(3)*I*(-1/(a**4*b**2))**(1/3)/18)*log(81*a**3*b*(-(-1/(a**4*b**2))**(1/3)/18
>> + sqrt(3)*I*(-1/(a**4*b**2))**(1/3)/18)**2 + x)
>
> If I recall correctly, this is what I did for the FriCAS interface. It would
> be nice to factor out any common functionality, if possible.
Obviously though the RootSum is better than the radicals which is why
it is used in the first place so the ideal solution would be to
preserve the RootSum. The simple case above already shows that it is
better but in others the radical formulae can explode and in more
complicated cases formulae won't even exist.
--
Oscar
--
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/CAHVvXxQVU9E_-JNtasmSc-McVbdts7tkQUhLBDjhKj11HDXMGg%40mail.gmail.com.
Re: [sage-devel] What was/is/will be the purpose of maintaining the Sage distribution?
On Thu, Apr 27, 2023 at 2:15 AM Matthias Koeppe
wrote:
>
> A previous sage-devel thread led to this question, which I think is important
> and timely to discuss.
>
> **What was/is/will be the *purpose* of maintaining the Sage distribution?**
> (Historically; as of today; and looking forward by a year or two.)
>
> Here are some of my thoughts on this question:
>
> 1. Ease of installation.
>
> Historically, an important purpose was to make loads of software packages,
> including many poorly maintained math software, easy to install.
> In particular -- easy to install for a user on a shared machine ("big
> department compute server") without root access.
> And in particular -- on shared machines with long outdated distributions
> ("Department IT installed it when the machine was bought, 10 years ago.")
>
> As of today, it is plausible that such situations still exist.
There is no "mystery HPC cluster" on the list of platforms supported
by Sage. I don't see a point in "what if" argument like this.
We know it's not possible to build a modern gcc using gcc5 or whatever
outdated thing there can be, and let us leave this
potential (and very small) segment alone.
> There are definitely still "shared compute server" situations (in particular,
> HPC clusters) where users cannot use container technology such as Docker and
> lxc, and therefore cannot use Linux distribution packaging solutions
> (archlinux, debian, ...). Overall I don't think we have sufficient insights
> about our worldwide user base to be sure. Here the Sage distribution still
> may have a value for users. Another option is non-root installable packaging:
> essentially, conda-forge (although nix and guix may be other options). But as
> I wrote earlier, there are still loose ends regarding Sage development in a
> pure conda environment (note that it is still marked as "experimental" in
> https://doc.sagemath.org/html/en/installation/conda.html#using-conda-to-provide-all-dependencies-for-the-sage-library-experimental),
> and also optional packages are missing.
>
> Going forward, if the loose ends are ironed out (I'm mixing metaphors for
> comical effect) and missing packages added, I think that Sage installation,
> use, and development can be fully supported on top of conda-forge. This takes
> engagement and work; and this could certainly be done faster if a decision to
> abandon the Sage distribution on a specific release / date is made, because
> then substantial resources are freed. A time frame of a year or two could be
> realistic.
>
> (I am also working on another deployment path using Python wheels, but this
> is much more work than just fixing the remaining conda-forge problems.)
>
>
> 2. Control of dependencies and the "many upstreams - many downstreams"
> problem.
>
> For Sage developers, the Sage distribution is a way to have direct control
> over all dependencies -- that's the Sage distribution's role as a "reference
> distribution".
>
> (This role has been weakened since we introduced the spkg-configure mechanism
> of working with system packages, of course. This is an activity that does
> make sense one package at a time, but details such as how strict we are in
> what we accept from the system matter; see Michael's thoughts in his message.)
At this point, you start contradicting yourself. There is no value,
only added costs of maintainance, in carrying on with spkgs for which
viable alternatives are available, and such packages may be dropped
from Sage, one at a time, with no loss whatsoever.
Primary candidates here are python3 and gcc, packages you refuse to
drop due to "lack of greater plan".
But there is no greater plan needed here, these are just dead meat
which only gets used in automated testing, if at all.
We have spent years running in a vicious circle of endless upgrades of
packages we can use from the OS, such a waste.
So my proposal is to drop python3 and gcc spkgs immediately, and
gfortran upon a bit of investigation (only needed on macOS).
The next in line will be jupyter and friends.
>
> But still the following points apply:
>
> a) If a critical bug is discovered, we can patch it and don't have to rely on
> people and infrastructure "outside the project" to fix things for us.
> Of course, we have been very lucky that packagers for many distributions have
> been consistently highly engaged with the project; but this is not something
> that we can take for granted.
>
> b) And, of course, more Sage developers can become contributors to the
> packaging communities; but there is the real danger that taking care of both
> upstream development *and* downstream packaging for the same project can lead
> to developer burnout.
We already have developer burnout, I myself am a prime example.
Dima
>
> c) There is a danger that our project's endorsing of a particular packaging
> solution (e.g. conda-forge) could alienate highly engaged packagers for other
> systems. And if left unchecked, it
