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 <isu...@gmail.com> 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 <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. -- 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/CACLE5GDe_Lc-mFRcyHTUhEmUKJyZZ-OBXGNmd9vewmo4F3VU9w%40mail.gmail.com.
