Remove gcc spkg, keep gfortran

[dimpase]

Discussions:

https://groups.google.com/g/sage-devel/c/cSsAsPuVnxg/m/yVSGUFi7BQAJ (June 2021)
https://groups.google.com/g/sage-devel/c/NfUKjAaTcUg/m/JwqDd7mVAwAJ (September 2021)
In this ticket:

Just downgrade the gcc spkg to experimental, to match our recommendations in the installation guide in #34528.
CC: @mkoeppe @vbraun @orlitzky @jhpalmieri

Component: packages: standard

Author: Dima Pasechnik

Branch/Commit: u/dimpase/packages/gcc_experimental @ 58ca5d2

Issue created by migration from https://trac.sagemath.org/ticket/32532

(NB: reverted to the original state; copuous edits by @mkoeppe, done in 2024 are still in history)

[dimpase]

comment:1

Dima's original ticket description:

This is a followup to #32060. Building gcc from source is very hard, and unnecessary for any platform Sage supports now.

Same applies to gfortran, with macOS being an exception - there is no (g)fortran coming from the system.

So we need such an easy to install replacement, e.g. one provided by Conda, Homebrew, MacPorts, etc.

Should the need arise for something more isolated, (hopefully not), there are experimental standalone distributions of gfortran for macOS, by the gfortran maintainer of the Homebrew package. This offers a way to entirety remove gcc and gfortran spkgs from Sage.

​https://github.com/fxcoudert/gfortran-for-macOS - specifically,
https://github.com/fxcoudert/gfortran-for-macOS/releases/tag/11.2-bigsur-intel
provides a signed and notarized installed of gcc 11.1 to /usr/local (I tested it, it works)

Other Fortran possibilities are various closed source offers, e.g. from Intel and NAG,
as well as open-source flang, etc.

[mkoeppe]

comment:3

There are no build problems with gfortran - #32060 comment:36

[dimpase]

comment:5

yet, building gfortran is useless waste of resources - it takes a lot of time, etc.

[mkoeppe]

comment:6

Removing it puts a fresh obstacle in the way of pip-installability -- no, thanks.

[jhpalmieri]

comment:7

Since removing gfortran is controversial, please drop the idea or discuss on sage-devel. It should not be settled here.

[dimpase]

comment:8

Replying to @mkoeppe:

Removing it puts a fresh obstacle in the way of pip-installability -- no, thanks.

how come removing gcc spkg does not create such an obstacle, whereas it does for gfortran?

Besides, if you need to build gcc in order to build gfortran, the latter cannot be counted as unproblematic.

[dimpase]

comment:9

still needs adding some Fortran to CI for the minimal macOS configuration.

---

Last 10 new commits:

48cdeb4	configure.ac, sage_spkg_configure.m4: Set default --with-system-gcc=force, --with-system-python3=force
8e92b98	tox.ini: Override new configure --with-system-python3=force default from #32060
19efe21	configure.ac: Revert the change to the default for --with-system-python3
c5e1dec	add gfortran to _prereq/distros
2482aa1	error out if C/C++ is not good enough
6366b2a	error out if no good Fortran found.
f103f2a	remove *gcc_spkg workflows
f58e236	correct the order of messages
657c1e0	adjust tox.ini for no gcc spkg
5461d81	correct order of messages

[dimpase]

Branch: u/dimpase/packages/removegcc

[dimpase]

Commit: 5461d81

[dimpase]

comment:10

also, CI tests for obsolete gcc-4 based distros are gone, about time.

[mkoeppe]

comment:11

Replying to @dimpase:

how come removing gcc spkg does not create such an obstacle, whereas it does for gfortran?

Python dev environments have a gcc. If they don't, we can't help them anyway.

Python dev environments don't have gfortran. gfortran is not pip-installable. The few Python packages that use gfortran have high-quality deployments of wheels to PyPI, which are widely used.

Sage does not (yet?) have a working strategy that would enable us to use wheels from PyPI. The first step to pip-installability in #29039 builds everything from source.

Besides, if you need to build gcc in order to build gfortran, the latter cannot be counted as unproblematic.

Come again? No, we don't do that on any platform.

[dimpase]

comment:12

Replying to @mkoeppe:

Replying to @dimpase:

how come removing gcc spkg does not create such an obstacle, whereas it does for gfortran?

Python dev environments have a gcc. If they don't, we can't help them anyway.

Python dev environments don't have gfortran. gfortran is not pip-installable.

gcc is not pip-installable, either. The only scenario where developers have no Fortran, but "gcc" (for some value of "gcc", e.g. Apple clang) is on macOS, as far as I know.
On macOS they'd have to help themselves by installing (g, or some other)fortran in some way.

Needless to say, we should test that this is feasible without using !Homebrew/Conda/macports,
say with the gfortran installer linked in the ticket description.

The few Python packages that use gfortran have high-quality deployments of wheels to PyPI, which are widely used.

Sage does not (yet?) have a working strategy that would enable us to use wheels from PyPI. The first step to pip-installability in #29039 builds everything from source.

OK, and this setting will need a Fortran compiler in addition to a C/C++ compiler.
Why is it an extra obstacle? It's an improvement, as it makes building a lot quicker.

Besides, if you need to build gcc in order to build gfortran, the latter cannot be counted as unproblematic.

Come again? No, we don't do that on any platform.

on gcc-4-based platforms we build gcc+gfortran, no?
(well, I am not worried about this obsolete case)

[mkoeppe]

comment:13

Replying to @dimpase:

Replying to @mkoeppe:

Replying to @dimpase:

how come removing gcc spkg does not create such an obstacle, whereas it does for gfortran?

Python dev environments have a gcc. If they don't, we can't help them anyway.

Python dev environments don't have gfortran. gfortran is not pip-installable.

gcc is not pip-installable, either.

Please... I just explained it.

"Python dev environments have a gcc". Why? Because lots of Python packages need a working C/C++ compiler.

I explained why the gfortran situation is different.

[dimpase]

comment:14

Replying to @mkoeppe:

Replying to @dimpase:

Replying to @mkoeppe:

Replying to @dimpase:

how come removing gcc spkg does not create such an obstacle, whereas it does for gfortran?

Python dev environments have a gcc. If they don't, we can't help them anyway.

Python dev environments don't have gfortran. gfortran is not pip-installable.

gcc is not pip-installable, either.

Please... I just explained it.

"Python dev environments have a gcc". Why? Because lots of Python packages need a working C/C++ compiler.

I explained why the gfortran situation is different.

It's not different, as Fortran compilers are easy to come by these days.

The philosophy of this ticket is that we should cut our losses we had while trying to vendor everything imaginable, spending human resources on thankless tasks such as vendoring gcc/gfortran,
something that 99.9% of Sage users don't care about.

[mkoeppe]

comment:15

-1 on creating new real problems in order to fix imaginary problems.

[dimpase]

comment:16

Replying to @mkoeppe:

-1 on creating new real problems in order to fix imaginary problems.

No Python project I know vendors compilers. Lack of developer time is very real problem, and you keep perpetuating this problem
by refusing to shed the ballast.

[dimpase]

Author: Dima Pasechnik

[dimpase]

comment:17

I did a run on GitHub Actions: https://github.com/dimpase/sagetrac-mirror/actions/runs/1258945033
(our macOS actions are broken, so no surprise it's not working there)

[mkoeppe]

comment:18

Let's please drop this.

[mkoeppe]

@dimpase Happy new year.

I have collected facts regarding gcc/gfortran in the Sage distribution in the PR description. Please take a look, and if you have any evidence regarding the costs of maintenance, please add the references here.

[dimpase]

Season's greetings.

I don't see how commits are relevant there.

I do recall a number of cases of Sage users who wanted a build from source and ended up trying to build gcc or gfortran spkg from source, including at least one of my students (3rd or 4th year), and and a few of our GSoC students who ran into this trap, too.

[mkoeppe]

I do recall a number of cases of Sage users who wanted a build from source and ended up trying to build gcc or gfortran spkg from source

Find them and link them, or I'll assume it happened before 2019.

[dimpase]

How on Earth do you expect me to provide a detailed evidence of complaints by students ?
"Dear Prof, I cannot build Sage. Can I drop by your office?"

Is it a trial?

[mkoeppe]

@dimpase In https://groups.google.com/g/sage-devel/c/RdSImkzRxJI/m/CMKBJ6u6BAAJ, you denounced my edit of the PR description as "questionable". What exactly is it that you find questionable.

[dimpase]

Why do you list all these commits there?

[mkoeppe]

The commits document the maintenance cost and who did the work.

[dimpase]

these are irrelevant.

[dimpase]

No amount of work done on a wrong design can justify keeping the wrong design around - and this is exactly what you are doing here.

"look, it's me, me, me, who did all the work, how dare you say it must go ?!"

[mkoeppe]

Neither do you get to declare it's "irrelevant", nor do you get to declare that it's "the wrong design". Try constructing an actual argument.

[dimpase]

I am saying that you don't have an argument for listing these commits there, because it is irrelevant who wrote that code.

If the code is useless then it has to go.

The only meaningful use of the gfortran spkg in the past years was @jhpalmieri use of gfortran during a few weeks Homebrew's gfortran was broken for a particular bleeding edge hardware and software platform, during a summer holiday season.

There was no meaningful use of the gcc spkg whatsoever.

[mkoeppe]

Dima, you publicly denounced my edits as "questionable", so you'll have to do a bit more work than just declaring the added info as "irrelevant".

[mkoeppe]

The only meaningful use of the gfortran spkg in the past years was @jhpalmieri use of gfortran during a few weeks Homebrew's gfortran was broken for a particular bleeding edge hardware and software platform, during a summer holiday season.

There was no meaningful use of the gcc spkg whatsoever.

Both of these declarations are false. It's OK if you don't know better. And it's not a big surprise that you don't know better -- because you have not been involved in the maintenance of these packages. That's one thing that is documented by the list of commits.

@dimpase replied by editing this comment:

no amount of meaningless work done justifies the meaningless work.

Sage would be much better served by removal of these spkgs.

[mkoeppe]

I've made it a principle of my work to assume that others act in good faith, and have been willing to take this principle to extremes. Because of this, my interpretation is simply that you cannot trust your memory on which you base your repeated declarations (which are not supported by facts).

Despite the absoluteness of the types of declarations that you are making ("no meaningful use whatsoever" etc.), in the end your line of reasoning is a cost-benefits analysis.

That's why I have spent the time to collect and organize the facts regarding costs and benefits in the ticket box. You are welcome to help with this collection and organization.

[dimpase]

I've made it a principle of my work to assume that others act in good faith, and have been willing to take this principle to extremes. Because of this, my interpretation is simply that you cannot trust your memory on which you base your repeated declarations (which are not supported by facts).

the problem is that you assume that others act in good faith, but I increasingly see you not acting in good faith.

Just look at the number of U-turns you made on this ticket - with an obvious intention to stop it by whatever means.

[dimpase]

Dima, you publicly denounced my edits as "questionable", so you'll have to do a bit more work than just declaring the added info as "irrelevant".

You can only justify packaging gcc and gfortran if you are trying to build a (badly designed) clone of Conda.

If you are building a clone of Conda then it's high time to fork sagelib, and run away.

If you are not building a clone of Conda then gcc and gfortran are good to go.

[mkoeppe]

I increasingly see you not acting in good faith.

You have said that and made worse accusations regarding my intent many times already, in #36726 and other places. This is abusive conduct. I've called you out on it on many times. That you keep continuing with it is a display of disrespect.

[dimpase]

You've earned the disrespect, don't you see it?

[dimpase]

There is nothing abusive in pointing out that your point of view here is wrong, because it is. No matter how much meaningless data you pile up, a wrong design is wrong design.

[jhpalmieri]

Please stop all discussion and other activity here. It is not accomplishing anything positive, and it could very well be causing harm: as with many of your other recent "discussions," if someone from outside stumbled onto them, they would be driven away from participating in Sage development. People already involved in Sage development may also be driven away. In other words, your actions are potentially causing direct harm to Sage development.

[williamstein]

Agreed. Please stop all discussion and other activity here. Go to [1] if you really must continue this discussion publicly.

[1] https://groups.google.com/g/sage-flame

[saraedum]

While I understand that there is a "dispute" here, we are since https://groups.google.com/g/sage-devel/c/IgBYUJl33SQ using the "disputed" label to mark PRs that require a vote. As discussed with the Code of Conduct committee I updated the description of the label to reflect that.

If you want to point out comments that you think violate our Code of Conduct, then such violations should be reported to the committee. We will then decide whether to hide/delete these comments.

[mkoeppe]

If you want to point out comments that you think violate our Code of Conduct, then such violations should be reported to the committee. We will then decide whether to hide/delete these comments.

That reporting was already done long ago. Still waiting for an acknowledgment from the committee.