-
-
Notifications
You must be signed in to change notification settings - Fork 487
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use meson instead of configure for conda install #36489
Conversation
This reverts commit 9694046.
@@ -0,0 +1,40 @@ | |||
project('sage', 'c') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd be more comfortable with this file being local to sage-conf_meson, so as not to create expectations that Sage-the-distribution will switch to meson
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The idea in the middle to long term is to support running meson compile
from the root directory to compile sagelib with meson (using conda). For this the meson build file needs to be there (and its pretty much convention to have such a build file in the root). Sage-the-distro supporting meson would mean that there is a meson file in the build directory, or not?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not aware of such a plan, and I'd suggest that if you have a plan to use a new Issue in which you explain it.
From what you wrote above, it seems unlikely that it would be the same meson.build file that would be suitable for both purposes, so nothing is gained by putting it there.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's part of #34630. In the long-term you want to use of course meson-python (configured via pyproject.toml). But in the short to midterm its easier to just call meson directly. That's at least how scipy/numpy proceeded: https://github.com/scipy/scipy/pull/14847/files#diff-e42998d51257e6f84aa51ffa5f4ed1544cb12f97a94978c44f3bc281b5324d79R390-R500
And yes, the meson file added in this PR can be used for this purpose. In fact, I believe we can get ride of the conf and setup packages, but of course there still needs to be some way to provide the runtime-config (probably by just putting the generated conf file in the correct place in the builddir).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, #34630 has nothing to with stuff that belongs in SAGE_ROOT.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So it's for compiling the Sage library, for the single use case of the all-conda install?
There is nothing conda-specific about the meson files, it's only that conda provides a nice fixed environment and thus is a good starting point. You can try to run meson setup
outside of a conda environment and it should work (if you have all the necessary packages installed in the system).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll explain and summarize once more:
- What you just described ("it should work (if you have all the necessary packages installed in the system).") means that you are configuring / building the Sage library.
- This is different from what our
configure.ac
andMakefile
do. They configure / build the Sage distribution. - There is no plan to switch the Sage distribution to using meson.
- When people see a file
meson.build
next toconfigure.ac
andMakefile
, they are bound to think that using meson is an alternative for building the same thing. So this has the potential to mislead.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- When people see a file
meson.build
next toconfigure.ac
andMakefile
, they are bound to think that using meson is an alternative for building the same thing. So this has the potential to mislead.
So if you see a hammer and a saw next to each other you are bound to see them as alternatives for building the same thing?
Conceptually, meson setup
does the same thing as configure
: go through the declared dependencies and write out a config file. Similarly, meson compile
will do the same thing as make sage-all
(or whatever the correct target is for building sagelib).
It's also not technically possible to move the meson file in the root to src
since meson's subdir
only walks down the tree.
Anyway, I'm tired of this stupid discussion and will stop participating in it. If you think that the harm created by the meson file in the root outweighs the positives of this PR, then please go ahead and continue blocking it. Please leave the "ready for review" tag on, as there are no work items that referee and PR creator agree on (it just that you don't like a small design choice in the PR).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Similarly,
meson compile
will do the same thing asmake sage-all
(or whatever the correct target is for building sagelib).
The target make sage-all
does not exist. make all
, the default target, builds the Sage distribution.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry, but there are a lot of files in the root folder that are not related to the distribution.
[...] tox ini [...]
Actually SAGE_ROOT/tox.ini
defines the portability tests of the Sage distribution.
pkgs/sage-conf_meson/sage_conf.py
Outdated
from _sage_conf.__main__ import _main | ||
|
||
from builddir._conf import * | ||
from builddir.build_info import CONDA_PREFIX, SAGE_ROOT |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This "from builddir... import" makes me a bit uncomfortable.
This seems to assume that .
is in sys.path
Please test that also non-editable installs (via wheels) of sage-conf_meson work.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The builddir
here is generated under pkgs/sage-conf_meson
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I knew that when I wrote the above. So?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't see the difference between configure
creating the _conf.py
file and here we are using meson
to create the builddir
folder. Can you please be more specific what problem you encounter?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't see the difference
In https://github.com/sagemath/sage/blob/develop/pkgs/sage-conf/sage_conf.py#L1 we have:
from _sage_conf._conf import *
_sage_conf
is an installed top-level package.
Here: from builddir._conf import *
builddir
is not an installed top-level package.
More questions?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
At this time, I don't have a comment on what variables provided by sage_conf are needed at the runtime of the Sage library.
That's my observation: apparently none. The fallbacks are good enough for conda.
You may be right about this, but a lot currently still depends on the assumption "$SAGE_LOCAL = $CONDA_PREFIX" (e.g., see #30914 for pointers), which is guaranteed by the all-conda installation instructions, but I am not sure that we will want to keep it in the future.
A problem with this assumption is that we currently have an inflexible either-or situation:
- We either take all packages from conda and do not use the Sage build system at all, for anything;
- or we use the Sage build system for everything and then cannot use Python packages from conda. (For the purpose of this discussion, let's ignore the
--enable-system-site-packages
switch.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sage-conf is a declared install-requires of sagelib, so some version of it needs to be installed.
So can I change that to an optional dependency? (since it seems to be optional)
No, by design it's required, but as is explained in https://github.com/sagemath/sage/blob/develop/pkgs/sage-conf/README.rst, you can pick your own implementation.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
At this time, I don't have a comment on what variables provided by sage_conf are needed at the runtime of the Sage library.
That's my observation: apparently none. The fallbacks are good enough for conda.
You may be right about this, but a lot currently still depends on the assumption "$SAGE_LOCAL = $CONDA_PREFIX" (e.g., see #30914 for pointers), which is guaranteed by the all-conda installation instructions, but I am not sure that we will want to keep it in the future.
A problem with this assumption is that we currently have an inflexible either-or situation:
* We either take all packages from conda and do not use the Sage build system at all, for anything; * or we use the Sage build system for everything and then cannot use Python packages from conda. (For the purpose of this discussion, let's ignore the `--enable-system-site-packages` switch.)
Right, but in the "we take everything from conda" the assumption will always be valid, right? So in this case we don't need a sage_conf package. If in the future some semi-mixed versions are supported, then this method needs its own sage_conf package.
So can I change that to an optional dependency? (since it seems to be optional)
No, by design it's required, but as is explained in https://github.com/sagemath/sage/blob/develop/pkgs/sage-conf/README.rst, you can pick your own implementation.
This document doesn't say anything on why we need the package nor why the design cannot be changed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Either way, I've fixed the package now. Please give it a try.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right, but in the "we take everything from conda" the assumption will always be valid, right?
My point is that this dichotomy of the two installation methods is not sustainable; so it would be unwise to be invested in a "pure" mode that seeks to eliminate sage_conf altogether.
This goes in a great direction, thanks for working on it. For the conda CI, I think it would be crucial to keep a run of the configure-based sage-conf_conda around, just for the tests that it runs (instead of just trusting that the package versions installed in the environment are OK). (For example, by building but not installing the sage-conf_conda wheel.) |
Thanks for the review. Should have addressed all points now. |
@mkoeppe "Please leave the "ready for review" tag on, as there are no work items that referee and PR creator agree on (it just that you don't like a small design choice in the PR)." from above. Thanks! |
There are clear work items. |
which is blocked for stupid reasons
Documentation preview for this PR (built with commit 7a44082; changes) is ready! 🎉 |
… `pyproject.toml` <!-- ^^^^^ Please provide a concise, informative and self-explanatory title. Don't put issue numbers in there, do this in the PR body below. For example, instead of "Fixes sagemath#1234" use "Introduce new method to calculate 1+1" --> <!-- Describe your changes here in detail --> <!-- Why is this change required? What problem does it solve? --> <!-- If this PR resolves an open issue, please link to it here. For example "Fixes sagemath#12345". --> - In part split out from sagemath#36489 - Part of sagemath#33577 <!-- If your change requires a documentation PR, please link it appropriately. --> ### 📝 Checklist <!-- Put an `x` in all the boxes that apply. --> <!-- If your change requires a documentation PR, please link it appropriately --> <!-- If you're unsure about any of these, don't hesitate to ask. We're here to help! --> <!-- Feel free to remove irrelevant items. --> - [x] The title is concise, informative, and self-explanatory. - [ ] The description explains in detail what this PR is about. - [x] I have linked a relevant issue or discussion. - [ ] I have created tests covering the changes. - [ ] I have updated the documentation accordingly. ### ⌛ Dependencies <!-- List all open PRs that this PR logically depends on - sagemath#12345: short description why this is a dependency - sagemath#34567: ... --> - Depends on sagemath#36533 (which changes setup.cfg, merged here) - Depends on sagemath#36885 <!-- If you're unsure about any of these, don't hesitate to ask. We're here to help! --> URL: sagemath#36561 Reported by: Matthias Köppe Reviewer(s): François Bissey
… `pyproject.toml` <!-- ^^^^^ Please provide a concise, informative and self-explanatory title. Don't put issue numbers in there, do this in the PR body below. For example, instead of "Fixes sagemath#1234" use "Introduce new method to calculate 1+1" --> <!-- Describe your changes here in detail --> <!-- Why is this change required? What problem does it solve? --> <!-- If this PR resolves an open issue, please link to it here. For example "Fixes sagemath#12345". --> - In part split out from sagemath#36489 - Part of sagemath#33577 <!-- If your change requires a documentation PR, please link it appropriately. --> ### 📝 Checklist <!-- Put an `x` in all the boxes that apply. --> <!-- If your change requires a documentation PR, please link it appropriately --> <!-- If you're unsure about any of these, don't hesitate to ask. We're here to help! --> <!-- Feel free to remove irrelevant items. --> - [x] The title is concise, informative, and self-explanatory. - [ ] The description explains in detail what this PR is about. - [x] I have linked a relevant issue or discussion. - [ ] I have created tests covering the changes. - [ ] I have updated the documentation accordingly. ### ⌛ Dependencies <!-- List all open PRs that this PR logically depends on - sagemath#12345: short description why this is a dependency - sagemath#34567: ... --> - Depends on sagemath#36533 (which changes setup.cfg, merged here) - Depends on sagemath#36885 <!-- If you're unsure about any of these, don't hesitate to ask. We're here to help! --> URL: sagemath#36561 Reported by: Matthias Köppe Reviewer(s): François Bissey
As noted in sagemath#37024 and in sagemath#36489, `sage-conf` is actually not needed on a few systems now. For this reason, we make the installation of it optional (as there are no optional install requires as far as I know, this means we remove it from `pyproject.toml` and `setup.cfg`). We also remove it from "install all dependencies via conda" as its not needed there.
As noted in sagemath#37024 and in sagemath#36489, `sage-conf` is actually not needed on a few systems now. For this reason, we make the installation of it optional (as there are no optional install requires as far as I know, this means we remove it from `pyproject.toml` and `setup.cfg`). We also remove it from "install all dependencies via conda" as its not needed there.
As noted in sagemath#37024 and in sagemath#36489, `sage-conf` is actually not needed on a few systems now. For this reason, we make the installation of it optional (as there are no optional install requires as far as I know, this means we remove it from `pyproject.toml` and `setup.cfg`). We also remove it from "install all dependencies via conda" as its not needed there.
No longer needed. |
Switches from
configure
to a simple meson-based setup (when using conda) by implementing asage-conf_meson
package that calls meson to looks for the dependencies. I've kept thesage-conf_conda
for now, as comparison and fall-back.This is preparation for #34630.
📝 Checklist
⌛ Dependencies