I have opened https://trac.sagemath.org/ticket/31485 - Meta-ticket: Sage on WSL (Windows Subsystem for Linux)
On Wednesday, March 10, 2021 at 1:10:01 PM UTC-8 emanuel.c...@gmail.com wrote: > On Tarc#31409 <https://trac.sagemath.org/ticket/31409>, E. Madison Bray > proposed to make R an optionalpackage only on Windows (which should be made > possible by an upcoming patch of Matthias Koeppe). > > I replied : > > Aaaaarghhh… > This would be a documentation nightmare (explaining why a ticket is > “optionally optional” is awkward at the very minimum…). It would also > “froze” the idea of Windows 10 being a “second-class citizen” as far as > Sage is concerned. > > I’m starting to consider promoting a WSL2 port as the preffered windows > platform,and preparing a deprecation of the Cygwin port, which remains > necessary as long as Windows versions <10 remain relevant only as rthe > “sanest” way out of this predicament (“sane” being an hyperbole, of > course…). > > This, IMHO, deserves further discussion. > > Le mercredi 10 mars 2021 à 13:30:06 UTC+1, erik....@gmail.com a écrit : > >> On Tue, Mar 9, 2021 at 6:13 PM Nathan Dunfield <nat...@dunfield.info> >> wrote: >> > >> > An update: I just tried three different binary versions on Linux: The >> Ubuntu 20.04 binary posted at SageMath.org, the sagemath/sagemath:develop >> Docker image, and conda on RHEL 7. None of them "just worked" with "sage -i >> foo". The Docker image and conda failed completely with >> > >> > make: *** No rule to make target 'all-toolchain'. Stop. >> > >> > I got farther with the Ubuntu binary. Choosing "sage -i pyflakes", it >> successfully pip-installed pyflakes and then started rebuilding all of Sage >> from scratch, starting with libpng, pkgconf, etc. So in some sense this >> worked --- I was able to abort the build and import pyflakes --- but in the >> end was equivalent to building Sage from source if I hadn't stopped it. >> >> Yes, this has been a persistent problem. It's a problem on >> Sage-Windows as well. In the past I've gotten it to work, but every >> time people make changes to the build system (which is often) it tends >> to break again, and as Matthias pointed out there is a not a >> well-established process for testing this (I try to test it manually >> but don't always remember to; or sometimes I do test it, but throw up >> my hands when it doesn't work because I don't want to hold up the >> release any longer). >> >> A big part of the problem is that the system for installing packages >> is badly interwoven with the build system for Sage itself. There is a >> good reason for this: If one of sagelib's build dependencies is >> changed, it is necessary to rebuild sagelib. >> >> For optional/experimental packages I think we should try to >> disentangle them a bit better from the "normal" build system. They >> really should be "drop-in" and not require a rebuild of sagelib. >> >> Part of my original goals for developing the "DESTDIR" build system >> was so that it would eventually be easier to build binary packages for >> optional packages. I wanted to be able to use this on Windows, for >> example, by allowing users to select optional packages by just >> unpacking pre-built tarballs, but I never got around to materializing >> that goal. Of course, if such a system did exist it should be >> available for other platforms as well. >> >> >> > On Tuesday, March 9, 2021 at 9:00:22 AM UTC-6 Nathan Dunfield wrote: >> >> >> >> To what extent does installing optional packages "just work" with the >> current binary distributions of Sage? I'm thinking of both those posted on >> sagemath.org as well as things not directly under our control such as >> the sage packages for conda, debian, gentoo, etc. My past experience has >> been that "sage -i foo" works only if I had built Sage from source, though >> I haven't tried any of the binaries recently. >> >> >> >> I bring this up because the user impact of moving R or any other >> package to optional depends tremendously on whether "sage -i R" just works. >> If switching R to optional is tantamount to requiring users of R to build >> all of Sage from source, that would be very disruptive for those users of R >> in Sage. Building Sage from source is a huge hurdle for 95% users and a >> nontrivial hassle for the rest. >> >> >> >> Best, >> >> >> >> Nathan >> > >> > -- >> > 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/4c6b267c-b29d-4aae-8bbd-f52f7f9ae820n%40googlegroups.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/e6c07a32-0b78-421f-bde6-8fcc6da7d93cn%40googlegroups.com.
