Improve configure's recommendations

[slel]

Dependencies, e.g. PPL for GLPK

On macOS with ppl installed via Homebrew,
the configure script reported the following:

## ---------------------------------------------------- ##
## Checking whether SageMath should install SPKG ppl... ##
## ---------------------------------------------------- ##
configure:27878: checking whether any of glpk gmp mpir
is installed as or will be installed as SPKG
configure:27882: result: yes; install ppl as well
configure:28277: no suitable system package found for SPKG ppl

and eventually recommended to brew install ppl.

It would seem that, in the above, this is correct:

configure:27878: checking whether any of glpk gmp mpir
is installed as or will be installed as SPKG
configure:27882: result: yes; install ppl as well

but this does not really follow:

configure:28277: no suitable system package found for SPKG ppl

In this case, because at least one of (glpk, gmp, mpir)
either was or would be installed as an SPKG, the script
concluded ppl should be installed as an SPKG too.

So the decision to install ppl was based on that,
not on the absence of ppl. In such a case, maybe
the script should not recommend installing ppl
(at least not without checking if it is actually there).

Initial report:
sage-release.

Python vs Python3, Python 3.7 vs Python 3.8

On macOS 10.14.6, as of July 2020, Homebrew installs Python 3.8.

Still, configure, looking for Python 3.7, recommends to brew install python3.

See also

• Meta-ticket: Refactor and improve system package related scripts, tox.ini, build/bin/write_dockerfile.sh #29146: Meta-ticket: Refactor and improve system package related scripts, tox.ini, build/bin/write_dockerfile.sh

• refine definition of variable SAGE_NEED_SYSTEM_PACKAGES in m4/sage_spkg_collect.m4 #30863: refine definition of variable SAGE_NEED_SYSTEM_PACKAGES in m4/sage_spkg_collect.m4

CC: @mkoeppe @slel @mwageringel @dimpase @EmmanuelCharpentier

Component: build: configure

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

[slel]

comment:1

To reformulate:

• don't recommend installing a package via the system's
  package manager in case the decision to install as spkg
  was based on some dependency being installed,
  or about to be installed, as spkg

The relevant logic seems to be in m4/sage_spkg_collect.m4
or m4/sage_spkg_configure.m4.

[mkoeppe]

comment:2

Thanks for creating the ticket! I've linked to it from #29146

[jhpalmieri]

comment:3

I think in this case we should change build/pkgs/glpk/distros/homebrew.txt to uncomment glpk. Then its installation would be recommended, and once it's found, homebrew's ppl would be used, too.

[mkoeppe]

comment:4

Or a bug report to homebrew should be made

[jhpalmieri]

comment:5

Reporting what bug? The messages that glpk prints that we in turn filter out?

[mkoeppe]

comment:6

Right... The comment "glpk 4.65 should not be used by Sage as long as it is not patched by Homebrew" comes from #24824.
We now (as of #29317) filter the messages out for the doctests -- but they are of course still an annoyance for users. I have not kept track of whether we have convinced any distributor to accept our GLPK patches that upstream didn't want. But we seem to be using the system package on all of arch, cygwin, debian, feora, gentoo -- so I guess with the filtered doctest messages it's good enough and we can re-enable the use of the homebrew package. I've opened #29587 for this.

[dimpase]

comment:7

The main GLPK dev seems to be too busy with other things. Last time he was talking about transferring maintainership to FSF, or something like this.

[slel]

comment:8

Thanks for opening and giving positive review to #29587, it's good we can use Homebrew's GLPK again.
I expanded the description at #29587 to include context and links about this GLPK issue.

The present ticket would still make sense, and is not specifically about the glpk or ppl issue.

[mkoeppe]

comment:9

Replying to @slel:

Thanks for opening and giving positive review to #29587, it's good we can use Homebrew's GLPK again.
I expanded the description at #29587 to include context and links about this GLPK issue.

Thanks a lot.

The present ticket would still make sense, and is not specifically about the glpk or ppl issue.

I agree.

[mkoeppe]

comment:13

Setting new milestone based on a cursory review of ticket status, priority, and last modification date.

[slel]

comment:14

New related report:

• sage-devel, 2021-02-26