Remove ./configure --enable-SPKG options for pip packages (for which this is not implemented)
Closed this issue · 38 comments
As reported in https://groups.google.com/d/msg/sage-release/6hBUt5i9FLs/RM-2eCdcBgAJ:
It seems that if I do
./configure --enable-beautifulsoup4
or
./configure --enable-pyopenssl
I get
make[3]: *** Aucune règle pour fabriquer la cible « /home/slabbe/GitBox/sage/local/var/lib
/sage/installed/beautifulsoup4-none », nécessaire pour « all-sage ». Arrêt.
make[3]: *** Attente des tâches non terminées....
...
make[3]: *** Aucune règle pour fabriquer la cible « /home/slabbe/GitBox/sage/local/var/lib/sage/installed/pyopenssl-none », nécessaire pour « all-sage ». Arrêt.
...
and make stops with an error.
We remove these options as a quick fix for 9.1. Follow-up could be in #29097.
CC: @seblabbe @dimpase @jhpalmieri @orlitzky
Component: build: configure
Author: Matthias Koeppe
Branch/Commit: 2bb7d75
Reviewer: Sébastien Labbé, John Palmieri
Issue created by migration from https://trac.sagemath.org/ticket/29626
Related to #29113 and #29481, I'm guessing. See also #29418 comment:23.
It's trying to use a target that does exist for the case of pip packages. See macro PIP_PACKAGE_templ in build/make/Makefile.in
For 9.1 a quick fix could be to disable the --enable-SPKG options for pip packages.
Author: Matthias Koeppe
Description changed:
---
+++
@@ -21,3 +21,7 @@
and make stops with an error.
```
+
+We remove these options as a quick fix for 9.1. Follow-up could be in #29097.
+
+I suggest also removing this message in src/bin/sage:
if [ -n "$ENABLE_ARGS" ]; then
echo >&2 "Hint: These optional/experimental packages can also be configured"
echo >&2 "to be installed by passing$ENABLE_ARGS to ./configure"
fi
Or make it conditional on the type of package, but that seems a bit involved.
What is standard ./configure behavior regarding bad flags? I see
$ ./configure --enable-pyflakes
configure: WARNING: unrecognized options: --enable-pyflakes
and then the warning message gets swept off the screen by all of the other messages. Should this be printed as part of a summary? Or do we assume that a user who knows enough to try something like this also knows enough to pay attention?
Branch pushed to git repo; I updated commit sha1. New commits:
9d09cf4 | src/bin/sage: Remove hints recommending ./configure --enable-SPKG |
Replying to @jhpalmieri:
I suggest also removing this message in
src/bin/sage:if [ -n "$ENABLE_ARGS" ]; then echo >&2 "Hint: These optional/experimental packages can also be configured" echo >&2 "to be installed by passing$ENABLE_ARGS to ./configure" fi
Done. Let's revisit this in the next release cycle.
Or make it conditional on the type of package, but that seems a bit involved.
I agree, too complicated
Replying to @jhpalmieri:
What is standard
./configurebehavior regarding bad flags? I see$ ./configure --enable-pyflakes configure: WARNING: unrecognized options: --enable-pyflakesand then the warning message gets swept off the screen by all of the other messages. Should this be printed as part of a summary? Or do we assume that a user who knows enough to try something like this also knows enough to pay attention?
That's normal and this part is not really configurable in autoconf.
One can disable these warning using --disable-option-checking, but I don't think there is an option to change these warnings to errors.
Regarding the new message in sage_spkg_collect.m4: sage -i PKG and make PKG both seem to work, and so does sage --pip install PKG. Is there any reason to prefer any of these? (Well, sage -i PKG does other stuff, too, so that one isn't as good, in my opinion.)
In fact, I would prefer make PKG, since it works with a fresh tarball, whereas sage --pip install PKG doesn't do what I want: since I'm using the system Python, it installs the package in the system location, not in SAGE_ROOT/local/... make PKG installs in the correct place.
Thanks for catching this. That's an important point
Branch pushed to git repo; I updated commit sha1. New commits:
2bb7d75 | m4/sage_spkg_collect.m4: Recommend 'sage -i' to install pip packages |
Replying to @jhpalmieri:
In fact, I would prefer
make PKG, since it works with a fresh tarball, whereassage --pip install PKGdoesn't do what I want: since I'm using the system Python, it installs the package in the system location, not in SAGE_ROOT/local/...make PKGinstalls in the correct place.
I have created a separate isssue for this: #29627 ("sage -pip" should never install into the system Python's site-packages)
I am using sage -i PKG in the message instead of make PKG because I'm not sure if we should advertise the latter.
(sage -i is already documented.)
Replying to @mkoeppe:
I am using
sage -i PKGin the message instead ofmake PKGbecause I'm not sure if we should advertise the latter.
I thought it's the plan to move to using make instead of sage -i
I can't reproduce the problem this ticket is meant to solve.
Replying to @dimpase:
I can't reproduce the problem this ticket is meant to solve.
To be honest, I was using configure with other options. Let me try again the minimal example... On my working installation of 9.1.rc2, if I do:
./configure --enable-pyopenssl
make
I get
make[3]: *** Aucune règle pour fabriquer la cible « /home/slabbe/GitBox/sage/local/var/lib/sage/installed/pyopenssl-none », nécessaire pour « all-sage ». Arrêt.
make[3] : on quitte le répertoire « /home/slabbe/GitBox/sage/build/make »
Makefile:1841 : la recette pour la cible « all-start » a échouée
make[2]: *** [all-start] Erreur 2
make[2] : on quitte le répertoire « /home/slabbe/GitBox/sage/build/make »
real 1m40.559s
user 1m29.896s
sys 0m10.192s
***************************************************************
Error building Sage.
The following package(s) may have failed to build (not necessarily
during this run of 'make all-start'):
It is safe to delete any log files and build directories, but they
contain information that is helpful for debugging build problems.
WARNING: If you now run 'make' again, the build directory of the
same version of the package will, by default, be deleted. Set the
environment variable SAGE_KEEP_BUILT_SPKGS=yes to prevent this.
Makefile:31 : la recette pour la cible « all-start » a échouée
make[1]: *** [all-start] Erreur 1
make[1] : on quitte le répertoire « /home/slabbe/GitBox/sage »
Makefile:13 : la recette pour la cible « all » a échouée
make: *** [all] Erreur 2
which confirms the issue on my machine.
Notice also that the list of The following package(s) may have failed to build is empty which is kind of weird and which made me search longer to discover the problem.
Reviewer: Sébastien Labbé
With the branch applied, I confirm that it is not documented anymore:
$ ./configure --help | grep pyopenssl
$ ./configure --help | grep fricas
--enable-fricas={no|if_installed|yes}
enable build and use of the optional package fricas
package information: ./sage -info fricas
--disable-fricas disable build and uninstall if previously installed
by Sage in PREFIX; same as --enable-fricas=no
But still, if I decide to do it, then
./configure --enable-pyopenssl
prints the warning configure: WARNING: unrecognized options: --enable-pyopenssl
And then
MAKE='make -j8' make
finishes without error.
And as expected, pyopenssl is not installed:
$ sage -optional | grep pyopenssl
pyopenssl...............................19.1.0 (not_installed)
To me it is a positive review (for the behavior). I did not check the code itself. So I let John or Dima or someone else to change the status of the ticket to positive review if that part is good too.
Replying to @dimpase:
I thought it's the plan to move to using
makeinstead ofsage -i
I also thought that (well read it from previous very involved developpers).
I don't see how to obtain the message that tells me to make pyopensl or sage -i pyopenssl ?
It is displayed during the package summary at the end of the ./configure run.
Replying to @dimpase:
Replying to @mkoeppe:
I am using
sage -i PKGin the message instead ofmake PKGbecause I'm not sure if we should advertise the latter.I thought it's the plan to move to using
makeinstead ofsage -i
My plan is to fully support ./configure --enable-PKG. But this feature is not ready for pip packages for the 9.1 release.
I don't know whose plan it was to make make PKG the advertised interface. There is no ticket that outlines this plan as far as I can see.
Changed reviewer from Sébastien Labbé to Sébastien Labbé, John Palmieri
We can leave it as is, but there is a significant difference between sage -i PKG and make PKG: the former installs the package (and its prereqs) and then builds all of Sage, while the second just installs the package (and its prereqs).
That's right. Which is part of why I don't want to advertise make PKG to Sage users. It's for advanced developer use, I would say.
Thanks for reviewing!
Changed branch from u/mkoeppe/__configure___enable_spkg_does_not_work_for_optional_pip_packages to 2bb7d75