> 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 <wst...@gmail.com> 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 <kcris...@gmail.com> 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, 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://groups.google.com/d/msgid/sage-devel/8b0c2df5-c3be-406c-a1fd-fd0506e5f946n%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/CACLE5GCTmMFcJw_mw2_UJKu4H6nvhOCJ0t5sbUoT1a090sh2aw%40mail.gmail.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%2B01voOHYPmYOUm8_2AAoPcPibXbHS3sZ_-BM9PfwoJ%2BXpu4zg%40mail.gmail.com.
