configure --disable-notebook: Also disable jupyter_sphinx
#38224
Conversation
|
Need to conditionalize |
mkoeppe
force-pushed
the
jupyter_sphinx_optional
branch
3 times, most recently
from
a304a76
to
a33d5de
Compare
|
Documentation preview for this PR (built with commit 33a114c; changes) is ready! 🎉 |
mkoeppe
force-pushed
the
jupyter_sphinx_optional
branch
from
a33d5de
to
235bce6
Compare
mkoeppe
force-pushed
the
jupyter_sphinx_optional
branch
from
235bce6
to
50d9337
Compare
|
This beta's no better than the last one for me: I'm going back outside. |
|
I think @kiwifb can tell you about this gentoo-specific problem |
|
@orlitzky you are officially bitten by cschwan/sage-on-gentoo#783 the good news is that upstream accepted to fix it and an appropriate version of scikit-build-core is in the gentoo tree. |
Yep, that was it. Upgrading fixed it. Thanks! |
|
Further, at least: |
Is there a discussion on this policy? What is the rationale of the policy? It (disabling a standard package) sounds like a oxymoron to me... |
|
To me, a standard package is simply one that is configured to be installed by default. |
|
"disabling standard package" sounds strange but is okay. My question is rather on "must be". Why "must be a configure option" for "platform-dependent wheel"? |
|
I get but the part covered by |
Currently, standard Sage can be built from source, so (at least in theory) on a wide range of architectures. If we allow standard packages to be provided by platform-dependent wheels, that restricts such packages to the fixed range of architectures for which wheels have been provided. This could be highly controversial, which is why I am proposing the conservative policy in #38219 that such packages at least must have a |
I understand up to this point.
Let's assume a platform on which the standard package has no wheel yet. What should happen to the package when sage is built on that platform? Failure? So |
Not just "not yet": Making wheels for the packages is not under the control of our project.
Yes, it's a hard error.
Exactly. |
mkoeppe
force-pushed
the
jupyter_sphinx_optional
branch
from
93a2b83
to
1db6f85
Compare
mkoeppe
force-pushed
the
jupyter_sphinx_optional
branch
from
1db6f85
to
33a114c
Compare
|
This PR gives me a philosophical confusion about the meaning of standard packages in sage. A standard package is installed by default. Hence code in sage assumes its existence (or rather the functions provided by the package). The code in this PR allows the possibility that the feature provided by a standard package may not exist. Don't we have "optional package" just for the case? I think there is no essential difference between (S) standard package that may be disabled and (O) optional package that may be enabled. On the other hand, I am aware that similar blurring was already introduced into the sage library through the modularization... |
Exactly, and that's the complete answer. |
No, an optional package is not installed by default. |
Do we have a precedence that a standard package can be disabled and the possibility is reflected in sage code? |
|
Yes, there are a bunch of |
Yes, you can find a bunch of |
|
Package-wise, I see only three relevant cases: R is an optional package. I don't understand why So cvxopt and notebook are relevant examples of standard packages that can be disabled. I think these are rather exceptions, made for practical purposes. If an arbitrary standard package can be disabled in principle, then code in sage should spend time checking its availability before doing anything useful. For example, Singular is a standard package, and the code in sage relying on Singular can assume its existence. I cannot agree with your definition of standard packages. Since notebook is already an exception, perhaps jupyter-sphinx may be treated also as an exception -- standard package that can be disabled and hence needs to be checked for its availability. We may call this "semi-standard"... |
|
Yes, and the various |
|
Thank you! |
…er_sphinx`
<!-- ^ Please provide a concise and informative title. -->
<!-- ^ Don't put issue numbers in the title, do this in the PR
description below. -->
<!-- ^ For example, instead of "Fixes sagemath#12345" use "Introduce new method
to calculate 1 + 2". -->
<!-- v Describe your changes below in detail. -->
<!-- v Why is this change required? What problem does it solve? -->
<!-- v If this PR resolves an open issue, please link to it here. For
example, "Fixes sagemath#12345". -->
`jupyter_sphinx` is only needed for the live documentation and for some
illustrations in `src/doc/en/tutorial/latex.rst`.
We conditionalize the use of this extension using a Feature.
`configure --disable-notebook` now also disables `jupyter_sphinx`, to
avoid pulling in lots of Jupyter packages via its dependencies
(including `jsonschema`, which has gotten itself a Rust-based
dependency, see sagemath#38219).
This implements the policy for use of platform-dependent wheels proposed
in sagemath#38219 ("if a platform-dependent ``wheel`` package is a standard
package, there must be a ``configure`` option that disables it").
We also repair the mechanism for conditional documentation based on
feature tags.
In particular, the link for Boolean polynomials is restored.
https://doc-pr-38224--
sagemath.netlify.app/html/en/reference/polynomial_rings/#boolean-
polynomials
### 📝 Checklist
<!-- Put an `x` in all the boxes that apply. -->
- [x] The title is concise and informative.
- [x] 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 and checked the documentation
preview.
### ⌛ Dependencies
<!-- List all open PRs that this PR logically depends on. For example,
-->
<!-- - sagemath#12345: short description why this is a dependency -->
<!-- - sagemath#34567: ... -->
- Depends on sagemath#38468 (merged here)
URL: sagemath#38224
Reported by: Matthias Köppe
Reviewer(s): Kwankyu Lee
jupyter_sphinxis only needed for the live documentation and for some illustrations insrc/doc/en/tutorial/latex.rst.We conditionalize the use of this extension using a Feature.
configure --disable-notebooknow also disablesjupyter_sphinx, to avoid pulling in lots of Jupyter packages via its dependencies (includingjsonschema, which has gotten itself a Rust-based dependency, see #38219).This implements the policy for use of platform-dependent wheels proposed in #38219 ("if a platform-dependent
wheelpackage is a standard package, there must be aconfigureoption that disables it").We also repair the mechanism for conditional documentation based on feature tags.
In particular, the link for Boolean polynomials is restored. https://doc-pr-38224--sagemath.netlify.app/html/en/reference/polynomial_rings/#boolean-polynomials
📝 Checklist
⌛ Dependencies