--
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/0f71e2d0-8834-4688-b110-55cd308d2ddbn%40googlegroups.com.
The question is whether the R interface will remain even marginally usable once downgraded to optional. It's fine to have optional packages, as long as there is a clear way to install them and that this is tested. Will this happen? R seems like an awfully big part of "viable competitor" to let that happen to.
On Monday, March 8, 2021 at 3:53:33 AM UTC-5 Volker Braun wrote:There are way better distributions of R than ours, just install one of these and the R interface will still work. In fact, if you rely on R then you shouldn't be using the outdated version in Sage...On Monday, March 8, 2021 at 5:22:12 AM UTC+1 John H Palmieri wrote:Dear all,You should be aware that ticket #31409 (https://trac.sagemath.org/ticket/31409) intends to downgrade R to an optional package because of difficulties building it on Cygwin. Just letting you know in case you care about R being part of Sage and/or you have ideas about how to fix the Cygwin build.(The branch there to downgrade R already has a positive review, by the way. I have no position on this, but I thought that more Sage developers should be aware.)--John
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/e2bd0b88-baea-4c7d-94b8-9f519addd2d3n%40googlegroups.com.
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.
Best,
Nathan
An alternative would be to create an alternative Windows port relying on WSL2 (which essentially runs a Linux kernel and a Linux distribution on top of Windows, in native mode and with few performance impact), possibly presenting less maintenance problems. This would, however, exclude support of any Windows version earlier than recent Windows 10. Is that a problem ? [...] Furthermore, to be realistic, we should be able to commit ourselves to maintain a binary distribution for at least one WSL2-supported Linux platform.
Would it be possible to keep the R *interface* standard while relying on the target platform(s) to provide the R interpreter itself (in Cygwin-over-Window's case, the Cygwin "port"...). However, this would create a dependence on Cygwin's version of R, not necessarily synchronized with the one supported by Sage on other platforms.
We're also still stuck on an old version of R that has a security
vulnerability in CVE-2020-27637. [...] Keeping an old
version as a standard package in cases like that can force people to
install an insecure version of the package in addition to the secure
version they already have installed.
Maintaining R as a Sage package, given wide availability of R on systems Sage can run, is a burden. I would argue we ought to drop it, along with gcc/gfortran, patch, etc.
- On the gripping hand (;-)),
If it doesn't work with the one in Sage AND with user-provided, maybe saying "well, it's supported so we should drop R" is disingenuous; is that not also the case for the current release of Sage? Or did that only crop up in the current beta cycle?
On Tarc#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.
Until now, what i saw with WSL is that people have to install a
GNU/Linux distro within WSL, to log in on it and then install and run
Sage within WSL.
I wonder : is there a way to provide a windows executable installer that
boostraps the whole stack WSL/GNU/Linux/Sage and provides a desktop icon
that transparently starts Sage within WSL and opens a webbrowser within
windows that connects to the WSL/GNU/Linux/Sage/jupyter instance via
http ?
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 [...]
> 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. [...]
For what it's worth, I was unable to reproduce on my own machine the
problem with building R on Cygwin encountered by Matthias which
prompted this discussion. [...]
Since I can't reproduce the problem (yet, though I'm trying some
things) and since I build the Windows binary releases I'm less
inclined to think it's a blocker issue.