I repeat my strong objections to the proposed change -- which does not solve any problems and only creates new ones.
1. When you refer to the "huge time sink", I think you are referring to painful memories from some distant past. But we have no current or recent problem with either the gcc or gfortran package. I fixed the last problems with the gfortran package in early 2020; there have not been any problems since. 2. We used the gcc spkg as recently as this Spring, for the 9.3 release, in order to support Fedora 34, which had just switched to gcc 11. No other solution was proposed or feasible at the time because several of our standard packages were not ready for this compiler, and a Sage release was already long overdue. 3. Your claims regarding availability of the tools on users' systems are not substantiated. a) clang/clang++, other than the version on macOS, is NOT supported by the Sage distribution. Only recently we added tests for these compilers (https://trac.sagemath.org/ticket/30835), which revealed build problems that are still unresolved (https://trac.sagemath.org/ticket/32207). b) Any talk about FreeBSD is unsubstantiated, there is no systematic effort to support it or even test this environment. c) The use of any Fortran compiler other than homebrew's packaging of gfortran on macOS (and our gfortran spkg) is completely unexplored. Given the instability of homebrew -- as a rolling platform on which it is not possible to install a specific version, it would be reckless to tie ourselves to homebrew's gfortran as the only option. (An effort to support macports in https://trac.sagemath.org/ticket/31505 is stalled.) d) Our build on top of conda has been broken for months. 4. I want to caution about a single-user-system centric point of view. Non-root users on a multi-user unix system, or on a locked-down corporate laptop CANNOT install a system package. By removing SPKGs and demanding that the corresponding system package is available, we would make the Sage distribution harder to install for users, thus reduce the value that the Sage distribution provides for non-root users. 5. The gcc spkg is specifically used in building the binary distribution. Any discussion of removing the gcc/gfortran spkgs without including a discussion of deployment as the binary package is incomplete. Availability of the compilers at runtime is a key feature that we have advertised through facilities such as the magic %cython directive and others. 6. (As I explained before in https://trac.sagemath.org/ticket/32060#comment:36) There is a crucial distinction between the gcc and the gfortran package: On systems with a too old or otherwise broken gcc, our gcc spkg often cannot be installed, so the gcc spkg is not very useful for dealing with old compilers (but see the successful recent use in the Fedora 34 case mentioned above). On the other hand, on systems with a working gcc but a missing gfortran, building our gfortran spkg is robust, and having it makes our distribution useful for a wider range of users. 7. (As I explained before in https://trac.sagemath.org/ticket/32532#comment:11) in particular, Python users / developers generally have a working gcc (because many Python packages include extension modules that need to be compiled) but they have no need to have gfortran installed. The reason is that the few Python packages that use gfortran (such as scipy) have high-quality deployments of wheels to PyPI, which are widely used. Sage, however, does not yet have a working strategy that would enable us to use wheels from PyPI. As you know, I have been working on a PyPI-based deployment solution for Sage in https://trac.sagemath.org/ticket/29039; this builds everything from source. Note that Python goes a long way to allow ordinary (non-root) users to install packages, either in a virtual environment or in the user scheme (pip install --user). gfortran, obviously, is not pip-installable -- so Python users would again need root access to install a system package to get the compiler. The project of modularization and PyPI deployment (https://trac.sagemath.org/ticket/29705) is complicated enough. I would appreciate if we do not create artificial obstacles -- removing gfortran or whatever next package you assume is on "everyone's system". Matthias On Thursday, September 23, 2021 at 3:17:29 PM UTC-7 Dima Pasechnik wrote: > https://trac.sagemath.org/ticket/32532 > <https://trac.sagemath.org/ticket/32532#comment:21> proposes to remove > these packages as not needed, and a huge time sink for everyone involved. > > Rationale: nowadays every platform that Sage supports has said tools (or > their equivalents - e.g. clang/clang++ in case of macOS and FreeBSD) > available, if not outright as a system package, but surely with a very > minimal effort. > > There is no need to carry this baggage forward. > Moreover, it seems that Sage is the only Python library/platform around > which (potentially) vendors gcc/g++/gfortran. > > > -- 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/bfd20a60-70d5-49df-bfa3-9d53caa447f7n%40googlegroups.com.
