Downgrade R to optional? See #31409.

174 views
Skip to first unread message

John H Palmieri

unread,
Mar 7, 2021, 11:22:12 PM3/7/21
to sage-devel
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


Volker Braun

unread,
Mar 8, 2021, 3:53:33 AM3/8/21
to sage-devel
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...

kcrisman

unread,
Mar 8, 2021, 11:11:03 PM3/8/21
to sage-devel
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.

Matthias Koeppe

unread,
Mar 8, 2021, 11:31:29 PM3/8/21
to sage-devel
Yes, it is documented how to install optional packages. And Sage 9.3 is improving how optional packages are advertised (see https://wiki.sagemath.org/ReleaseTours/sage-9.3#Chapter_on_packages_in_the_Sage_reference_manual).
And yes, optional packages are automatically tested. https://github.com/sagemath/sage/actions/runs/630175019
And, of course, optional packages will bitrot away if nobody takes care of them. 

William Stein

unread,
Mar 9, 2021, 12:05:18 AM3/9/21
to sage-devel
Hi,

One related question: we tend to have a 1-year deprecation policy with Sage, and some could argue that removing R will break use of Sage that uses the R interface.  Should removing the R package from standard be subject to this deprecation policy or at least a shorter one (6 months)?

I was the one who added R to Sage long, long ago.  I don't feel strongly opposed to removing R today since (1) exactly what Volker says "There are way better distributions of R than ours,", and (2) I think the rest of the Sage library (what we've all written over the years) has ended up depending heavily on numpy/scipy and not at all on R.   I didn't know in 2006 (or whenever) how statistics in Sage would grow, or what it would depend on over the next 15 years.   Now the exact answer to that question is known, and the answer is definitely not: "Sage statistics will heavily depend on R".   

 -- William



--
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.


--

Matthias Koeppe

unread,
Mar 9, 2021, 12:49:19 AM3/9/21
to sage-devel
Downgrading the package from standard to optional is the remedy for an issue that is blocking the 9.3 release (standard package does not compile on the standard platform). This is not a question of policy - it's a practical question of putting together a working release.

Emmanuel Charpentier

unread,
Mar 9, 2021, 8:17:37 AM3/9/21
to sage-devel
I'm torn :

  • On one hand, R provides a lot (understatement...) of non-trivial numerical and data-processing-related algorithms. A large part of this "lot"  comes from user-written packages (17273 as of today), covering an unparalleled range of use cases ; a lot of them have no equivalent in Python's 291406 (as of today) packages...
  • On the other hand, Windows is the dominant platform among our non-scholar users (especially students) ; losing support for even a part of Sage's ability on this platform  should be a big no-no.
  • On the gripping hand (;-)), our current solution for Windows platform  rests squarely on the shoulders of E. Madison Bray, which accomplishes alone the astonishing feat of maintaining what amounts to a port (to an hostile platfotm) almost alone. 
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.
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 ? (This is not a rhetorical question, but a real one : I am aware that upgrading Windows is problematic in various cases, for various reasons...). Furthermore, to be realistic, we should be able to commit ourselves to maintain a binary distribution for at least one WSL2-supported Linux platform.

I wait for further discussion before voting one way or another...

HTH,

Michael Orlitzky

unread,
Mar 9, 2021, 9:13:38 AM3/9/21
to sage-...@googlegroups.com
On Mon, 2021-03-08 at 21:04 -0800, William Stein wrote:
> Hi,
>
> One related question: we tend to have a 1-year deprecation policy with
> Sage, and some could argue that removing R will break use of Sage that uses
> the R interface. Should removing the R package from standard be subject to
> this deprecation policy or at least a shorter one (6 months)?
>

If you happen to be on one of the platforms where R still works, you
can still install the optional package (or better yet, install R using
your package manager) to retain all of the old functionality.

If you're on one of the platforms where R is currently broken, nothing
is lost with respect to the new release.

We're also still stuck on an old version of R that has a security
vulnerability in CVE-2020-27637. It's a silly one, but distributions
are generally going to be working to eliminate the vulnerable versions
in favor or newer ones -- and this happens constantly. 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.


Dima Pasechnik

unread,
Mar 9, 2021, 9:20:04 AM3/9/21
to sage-devel


On Tue, 9 Mar 2021, 04:11 kcrisman, <kcri...@gmail.com> wrote:
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.

as long as r2py is alive and well, it can use the, hopefully up to date, R from the system.

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 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


Nathan Dunfield

unread,
Mar 9, 2021, 10:00:22 AM3/9/21
to sage-devel
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

E. Madison Bray

unread,
Mar 9, 2021, 10:40:13 AM3/9/21
to sage-devel
On Tue, Mar 9, 2021 at 2:17 PM Emmanuel Charpentier
<emanuel.c...@gmail.com> wrote:
>
> I'm torn :
>
> On one hand, R provides a lot (understatement...) of non-trivial numerical and data-processing-related algorithms. A large part of this "lot" comes from user-written packages (17273 as of today), covering an unparalleled range of use cases ; a lot of them have no equivalent in Python's 291406 (as of today) packages...
> On the other hand, Windows is the dominant platform among our non-scholar users (especially students) ; losing support for even a part of Sage's ability on this platform should be a big no-no.
> On the gripping hand (;-)), our current solution for Windows platform rests squarely on the shoulders of E. Madison Bray, which accomplishes alone the astonishing feat of maintaining what amounts to a port (to an hostile platfotm) almost alone.

FWIW, although I haven't kept up with the current problem(s?) with R
on Cygwin, I'm willing to look into solving those problems. I have
patched R for Cygwin before. There may also be patches from the
Cygwin package for R that we can use.

The R developers have been hostile in the past to accepting fixed for
Cygwin, but I have had no problems in the past getting patches into
the Cygwin packages.

I have no strong opinion otherwise on keeping R as a standard package
in Sage, though I have anecdotal experience that most serious R users
have no use for the R provided by Sage, and that our focus should be
on integrating with external R distributions. This does not
necessarily mean we have to let R support in Sage become dilapidated.
We *could* make make R a "semi-standard" package in that it is not
installed by default, but our buildbots, etc. either install it by
default or install and test against an external R on the relevant
platforms...

> Le lundi 8 mars 2021 à 05:22:12 UTC+1, John H Palmieri a écrit :
>>
>> 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
>>
>>
> --
> 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/17c8f3b8-d308-4a76-8498-f0a165947179n%40googlegroups.com.

Dima Pasechnik

unread,
Mar 9, 2021, 11:53:38 AM3/9/21
to sage-devel


On Tue, 9 Mar 2021, 15:00 Nathan Dunfield, <nat...@dunfield.info> 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.

We can distribute Sage with R provided (on systems where it works at all)
 

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.

Nathan Dunfield

unread,
Mar 9, 2021, 12:13:53 PM3/9/21
to sage-devel
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.  

Best,

Nathan




Matthias Koeppe

unread,
Mar 9, 2021, 12:32:58 PM3/9/21
to sage-devel
Yes, there is a big problem with the current binary distributions for all platforms. 
What seems to be missing is a procedure to test them before releasing them. 
For those interested in helping with this, see https://trac.sagemath.org/ticket/31133 (Meta-ticket: Making and testing binary distributions)


Matthias Koeppe

unread,
Mar 9, 2021, 12:46:31 PM3/9/21
to sage-devel
On Tuesday, March 9, 2021 at 5:17:37 AM UTC-8 emanuel.c...@gmail.com wrote:
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.

This is an important point. In fact, Ubuntu and perhaps other distributions that run on WSL (1 or 2) already package recent versions of Sage. 
So perhaps all we need to do is test that these packages work well; and then update our documentation to recommend one or the other to potential users on Windows. (For the issue of testing of downstream packaging of Sage - see https://trac.sagemath.org/ticket/29060)

Also other aspects of supporting Windows can be much improved by what basically amounts to writing documentation.

See 
https://trac.sagemath.org/ticket/31156 (Doc: Add instructions how to run Sage + Jupyter notebook in WSL, browser in Windows)
- https://trac.sagemath.org/ticket/31157 (Doc: Add instructions on how to run the SageMath jupyter kernel in WSL, add as a kernel to Jupyter running natively in Windows)



 

Matthias Koeppe

unread,
Mar 9, 2021, 1:59:13 PM3/9/21
to sage-devel
On Tuesday, March 9, 2021 at 5:17:37 AM UTC-8 emanuel.c...@gmail.com wrote:
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.

No, we are currently unable to use system R on Cygwin - see https://trac.sagemath.org/ticket/30163
That's exactly what makes this issue a blocker for 9.3 -- we are neither able to use system R, nor build our own copy on this platform.




 

Matthias Koeppe

unread,
Mar 9, 2021, 2:13:47 PM3/9/21
to sage-devel
On Tuesday, March 9, 2021 at 6:13:38 AM UTC-8 Michael Orlitzky wrote:
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.

We already use system R via the spkg-configure mechanism, so our outdated SPKG is only used if users are on unsuitable distributions or ignore the system package advice that ./configure prints. Except... on Cygwin, where use of system R is disabled because it does not work -- see https://trac.sagemath.org/ticket/30163

kcrisman

unread,
Mar 9, 2021, 11:33:41 PM3/9/21
to sage-devel
This has been a good conversation.  I think that, despite some emotional attachment to the R in Sage (and I've actually used it for research, because it was the only way to get a certain algorithm in Sage), having the R provided in Sage might not be necessary.

However, we definitely should have easy to read instructions that come up when anyone tries "R.<tab>"  without having a system install that directs them how to do this.  Any more than when one has a brand new Mac OS and one types "git" it tells you what to do to get the command line tools.  I wonder if we already have that - for instance, I believe the small groups library for GAP has a useful error message (though it has been a while since I had to install it, so that might be outdated).

As for Cygwin, that seems to me to be a red herring.  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?


kcrisman

unread,
Mar 9, 2021, 11:35:17 PM3/9/21
to sage-devel
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.

So Numpy no longer needs gfortran? https://numpy.org/doc/stable/user/building.html

kcrisman

unread,
Mar 9, 2021, 11:36:47 PM3/9/21
to sage-devel

  • On the gripping hand (;-)), 
I almost thought you were channeling Tevye: https://www.youtube.com/watch?v=bWGtjqv19ZA 

Matthias Koeppe

unread,
Mar 10, 2021, 1:06:01 AM3/10/21
to sage-devel
On Tuesday, March 9, 2021 at 8:33:41 PM UTC-8 kcrisman wrote:
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?

Sage 9.1 and 9.2 fully supported Cygwin at the times of their release; this included, of course, building R from source as an SPKG. (However, using system R did not work, and the same was true for system BLAS.)
Cygwin is a rolling-release platform: Packages are updated continuously. Even if we do not make any changes in Sage, something that used to work can suddenly stop working. A small number of Cygwin-specific tickets has been merged in the recent releases to fix what has stopped working. Well, what happened in the 9.3 cycle is that we can suddenly no longer build R from source. 

E. Madison Bray

unread,
Mar 10, 2021, 7:30:06 AM3/10/21
to sage-devel
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.

Emmanuel Charpentier

unread,
Mar 10, 2021, 4:10:01 PM3/10/21
to sage-devel

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.

Matthias Koeppe

unread,
Mar 11, 2021, 4:37:19 PM3/11/21
to sage-devel
I have opened https://trac.sagemath.org/ticket/31485 - Meta-ticket: Sage on WSL (Windows Subsystem for Linux)

Thierry

unread,
Mar 11, 2021, 4:55:54 PM3/11/21
to sage-...@googlegroups.com
Hi,

On Thu, Mar 11, 2021 at 01:37:19PM -0800, Matthias Koeppe wrote:
> I have opened https://trac.sagemath.org/ticket/31485 - Meta-ticket: Sage on
> WSL (Windows Subsystem for Linux)

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 ?

Ciao,
Thierry



>
>
> 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
> To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/e6c07a32-0b78-421f-bde6-8fcc6da7d93cn%40googlegroups.com.

Matthias Koeppe

unread,
Mar 11, 2021, 5:50:06 PM3/11/21
to sage-devel
On Thursday, March 11, 2021 at 1:55:54 PM UTC-8 Thierry (sage-googlesucks@xxx) wrote:
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 ?

https://trac.sagemath.org/ticket/30505 has some pointers that go into this direction.

Thierry

unread,
Mar 11, 2021, 5:56:54 PM3/11/21
to sage-...@googlegroups.com
Thanks.

>
> --
> 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/8922dd65-5d24-4e60-93b8-42c03ba171a0n%40googlegroups.com.

E. Madison Bray

unread,
Mar 12, 2021, 5:45:57 AM3/12/21
to sage-devel
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. To me, this suggests there is not a deep or
inherent problem with building R on Cygwin, and that the problem might
be localized to a specific configuration, possibly related to his CI
scripts. It definitely merits further investigation, but it is likely
a minor problem with linking or dependencies.

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. Though it is unfortunate that
it's breaking the CI and that should still get fixed.

Matthias Koeppe

unread,
Mar 23, 2021, 2:20:23 PM3/23/21
to sage-devel
I think a much easier and robust solution for the problem of optional packages for binary distributions would be the following:

In addition to the standard binary distribution, create a second monolithic binary distribution that ships "whatever packages happened to build without errors" -- with the exclusion of huge database packages (which are trivial to install because they do not involve compilation -- see also https://trac.sagemath.org/ticket/30914 "Meta-ticket: Create upstream repositories, pip-installable packages for database packages"). 

The distribution will be bigger than the standard binary distribution. But we have not heard complaints lately that "Sage does not fit on my disk".

The key bottleneck that we have is in developer time/attention to keep optional packages up to date and working on the various supported platforms. It is not disk space or download time. 


Those who are interested in more modular binary packaging may also want to check out https://trac.sagemath.org/ticket/31251 "Meta-ticket: Distribution as wheels".

On Wednesday, March 10, 2021 at 4:30:06 AM UTC-8 erik....@gmail.com wrote:
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. [...]

Matthias Koeppe

unread,
Jun 25, 2021, 12:00:11 AM6/25/21
to sage-devel
On Friday, March 12, 2021 at 2:45:57 AM UTC-8 erik....@gmail.com wrote:
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. 
 
Still missing: The Windows binary release for Sage 9.3.



 
Reply all
Reply to author
Forward
0 new messages