Restructure `sage.*.all` for modularization, replace relative by absolute imports #36676

mkoeppe · 2023-11-08T05:11:55Z

We restructure the all.py files for modularization.

Guided by the technical constraints outlined in https://groups.google.com/g/sage-devel/c/ozh-7ZZ848s, #35095 defines distribution packages (pip-installable packages) sagemath-{brial, combinat, eclib, flint, gap, giac, glpk, graphs, groups, homfly, lcalc, libbraiding, libecm, linbox, modules, mpmath, ntl, pari, plot, polyhedra, schemes, singular, standard-no-symbolics, symbolics}.

When a namespace package such as sage.misc is filled by modules from several distribution packages, we create modules named:

src/sage/misc/all__sagemath_environment.py
src/sage/misc/all__sagemath_objects.py
src/sage/misc/all__sagemath_repl.py

Import statements are moved from src/sage/misc/all.py to these files as appropriate, and src/sage/misc/all.py imports * from there.

Also some imports are replaced by lazy imports.

The new files provide the top level namespaces for the modularized distribution packages, thus enabling modularized testing.

This design was introduced in #29865 (merged in Jan 2022, early in the Sage 9.6 development cycle).

Moreover, applied a one-line command to replace relative by absolute imports, thus complementing #36666, which does not touch .all* files.

The changes to other files in sage.modules etc. come from the PRs #36597, #36572, #36588, #36589 merged here and do not need review.

📝 Checklist

The title is concise, informative, and self-explanatory.
The description explains in detail what this PR is about.
I have linked a relevant issue or discussion.
I have created tests covering the changes.
I have updated the documentation accordingly.

⌛ Dependencies

Depends on Replace relative imports by absolute ones in modules #36597 (merged here to resolve merge conflict)
Depends on Replace relative imports by absolute ones in categories #36572 (merged here to resolve merge conflict)
Depends on Replace relative imports by absolute ones in rings #36588 (merged here to resolve merge conflict)
Depends on Replace relative imports by absolute ones in a few packages #36589 (merged here to resolve merge conflict)
Depends on Autogenerate flint headers #36449 (merged here to resolve merge conflict)
Depends on add simple function to count irreducible polynomials over 𝔽q #36390 (merged here to resolve merge conflict)

dcoudert

The coding style can certainly be improved and the syntax used when importing multiple methods from a module could be unified.

I tried on Fedora 35 and it seems ok.

src/sage/arith/all__sagemath_objects.py

src/sage/calculus/all.py

src/sage/combinat/all__sagemath_combinat.py

src/sage/misc/all__sagemath_modules.py

src/sage/plot/plot3d/all.py

src/sage/rings/all__sagemath_gap.py

mkoeppe · 2023-11-10T17:09:33Z

I would be in favor of running tools like autopep8, ruff, or black on these files to implement a consistent style. I don't have a personal preference for any particular style, nor do I regularly use these tools for auto-formatting. So discussion, suggestion, help are all welcome.

tobiasdiez

I don't really like all these all files. They add a lot of noise without providing much added value. I thought a bit about alternatives and came up with the following idea:

Each distribution sets a global constant (say IS_CATEGORIES_DISTRO for the categories distro)
In the single all file, you then have blocks that conditionally import certain modules depending on these global flag.

In this way you can introduce as many distributions as you want without having many all files. This is similar to the TYPE_CHECKING flag used by pyright.

What do you think?

tobiasdiez · 2023-11-11T15:43:45Z

src/sage/algebras/steenrod/all.py

 from sage.misc.lazy_import import lazy_import
+lazy_import('sage.algebras.steenrod.steenrod_algebra', ['SteenrodAlgebra', 'Sq'])


Why convert this to a lazy import?

It was convenient in the modularization. Do you have a specific concern about it?

For another ticket: I think that SteenrodAlgebra (which I wrote) and other named algebras perhaps could be deprecated and accessed solely through the algebras catalog, as a way of cleaning up the namespace. (I have no concerns about lazy importing here, for what that's worth.)

It was convenient in the modularization. Do you have a specific concern about it?

Just that it makes it very hard to review this PR, as there are all these unrelated changes sprinkled in. Can you extract these lazy_import changes to a new PR please?

No, I don't believe this would be helpful for anything.

tobiasdiez · 2023-11-11T15:53:33Z

src/sage/categories/all.py

@@ -27,128 +27,128 @@
 from sage.misc.namespace_package import install_doc
 install_doc(__package__, __doc__)

-from . import primer
+from sage.categories import primer


Can you please revert these changes to modules that you don't touch otherwise. Just increases the diff unnecessarily and introduces merge conflicts with other PRs. E.g. these changes here are already included in #36572.

The point of the PR is to replace all the all files with the version provided here.

introduces merge conflicts with other PRs. E.g. these changes here are already included in #36572.

When the same change appears, git automatically resolves it.

The point of the PR is to replace all the all files with the version provided here.

How is this change relevant to the modularization?

This change is part of "replace relative by absolute imports", which is in the title of the PR.

Update: The PR mentioned above, #36572, was merged in develop.

There is still no logical connection between making the imports absolute and the modularization. Both touch the all files yes, but that doesn't mean they should be in the same PR.

mkoeppe · 2023-11-11T17:35:01Z

I thought a bit about alternatives and came up with the following idea:

Each distribution sets a global constant (say IS_CATEGORIES_DISTRO for the categories distro)

In the single all file, you then have blocks that conditionally import certain modules depending on these global flag.

In this way you can introduce as many distributions as you want without having many all files. This is similar to the TYPE_CHECKING flag used by pyright.

What do you think?

This idea does not work because after an all module is imported, it is in sys.modules and a subsequent import of it is a no-op.

mkoeppe · 2023-11-11T19:57:40Z

I would be in favor of running tools like autopep8, ruff, or black on these files to implement a consistent style. I don't have a personal preference for any particular style, nor do I regularly use these tools for auto-formatting. So discussion, suggestion, help are all welcome.

In particular: https://stackoverflow.com/questions/76771858/ruff-does-not-autofix-line-too-long-violation

So there is a choice between the style that autopep8 uses (autopep8 --in-place --select E501 --max-line-length=88 src/sage/**/all*.py):

diff --git a/src/sage/schemes/hyperelliptic_curves/all.py b/src/sage/schemes/hyperelliptic_curves/all.py
index e314dceb1e0..40c8b58e823 100644
--- a/src/sage/schemes/hyperelliptic_curves/all.py
+++ b/src/sage/schemes/hyperelliptic_curves/all.py
@@ -41,6 +41,7 @@ lazy_import('sage.schemes.hyperelliptic_curves.invariants',
             ['igusa_clebsch_invariants', 'absolute_igusa_invariants_kohel',
              'absolute_igusa_invariants_wamelen', 'clebsch_invariants'],
             deprecation=28064)
-from sage.schemes.hyperelliptic_curves.mestre import (Mestre_conic, HyperellipticCurve_from_invariants)
+from sage.schemes.hyperelliptic_curves.mestre import (
+    Mestre_conic, HyperellipticCurve_from_invariants)
 from sage.schemes.hyperelliptic_curves import monsky_washnitzer
 del lazy_import
diff --git a/src/sage/stats/hmm/all.py b/src/sage/stats/hmm/all.py
index d331f45b41c..2d88d943fb1 100644
--- a/src/sage/stats/hmm/all.py
+++ b/src/sage/stats/hmm/all.py
@@ -8,6 +8,7 @@
 # We lazy_import the following modules since they import numpy which slows down sage startup
 from sage.misc.lazy_import import lazy_import
 lazy_import("sage.stats.hmm.hmm", ["DiscreteHiddenMarkovModel"])
-lazy_import("sage.stats.hmm.chmm", ["GaussianHiddenMarkovModel","GaussianMixtureHiddenMarkovModel"])
+lazy_import("sage.stats.hmm.chmm", [
+            "GaussianHiddenMarkovModel","GaussianMixtureHiddenMarkovModel"])
 lazy_import("sage.stats.hmm.distributions", ["GaussianMixtureDistribution"])
 del lazy_import

and what black uses (black src/sage/**/all*.py):

--- a/src/sage/schemes/hyperelliptic_curves/all.py
+++ b/src/sage/schemes/hyperelliptic_curves/all.py
@@ -37,10 +37,21 @@ from sage.misc.lazy_import import lazy_import
 
 from sage.schemes.hyperelliptic_curves.constructor import HyperellipticCurve
 from sage.schemes.hyperelliptic_curves.kummer_surface import KummerSurface
-lazy_import('sage.schemes.hyperelliptic_curves.invariants',
-            ['igusa_clebsch_invariants', 'absolute_igusa_invariants_kohel',
-             'absolute_igusa_invariants_wamelen', 'clebsch_invariants'],
-            deprecation=28064)
-from sage.schemes.hyperelliptic_curves.mestre import (Mestre_conic, HyperellipticCurve_from_invariants)
+
+lazy_import(
+    "sage.schemes.hyperelliptic_curves.invariants",
+    [
+        "igusa_clebsch_invariants",
+        "absolute_igusa_invariants_kohel",
+        "absolute_igusa_invariants_wamelen",
+        "clebsch_invariants",
+    ],
+    deprecation=28064,
+)
+from sage.schemes.hyperelliptic_curves.mestre import (
+    Mestre_conic,
+    HyperellipticCurve_from_invariants,
+)
 from sage.schemes.hyperelliptic_curves import monsky_washnitzer
+
 del lazy_import
diff --git a/src/sage/stats/hmm/all.py b/src/sage/stats/hmm/all.py
index d331f45b41c..6c879e12f5d 100644
--- a/src/sage/stats/hmm/all.py
+++ b/src/sage/stats/hmm/all.py
@@ -7,7 +7,11 @@
 
 # We lazy_import the following modules since they import numpy which slows down sage startup
 from sage.misc.lazy_import import lazy_import
+
 lazy_import("sage.stats.hmm.hmm", ["DiscreteHiddenMarkovModel"])
-lazy_import("sage.stats.hmm.chmm", ["GaussianHiddenMarkovModel","GaussianMixtureHiddenMarkovModel"])
+lazy_import(
+    "sage.stats.hmm.chmm",
+    ["GaussianHiddenMarkovModel", "GaussianMixtureHiddenMarkovModel"],
+)
 lazy_import("sage.stats.hmm.distributions", ["GaussianMixtureDistribution"])
 del lazy_import

no work items

tobiasdiez · 2023-11-11T20:52:52Z

I thought a bit about alternatives and came up with the following idea:

Each distribution sets a global constant (say IS_CATEGORIES_DISTRO for the categories distro)

In the single all file, you then have blocks that conditionally import certain modules depending on these global flag.

In this way you can introduce as many distributions as you want without having many all files. This is similar to the TYPE_CHECKING flag used by pyright.
What do you think?

This idea does not work because after an all module is imported, it is in sys.modules and a subsequent import of it is a no-op.

Can you explain why one would import the all files multiple times? Is it not enough to import it once, determine which distros are installed and then import the correct submodules based on this info?

mkoeppe · 2023-11-11T21:05:25Z

Is it not enough to import it once, determine which distros are installed and then import the correct submodules based on this info?

No, the main purpose of the "all" files is to fill the top-level namespace. But the contents of a module such as sage.all should really not depend on what distributions happen to be installed; that would be a very problematic design.

Instead I define separate top-levels that are suitable for the separate testing of the distributions. (I've added a link on that to the ticket description.)

Edit: As I wrote in #36524 (comment), this is part of the solution of how to test things when not all of sage.all can be imported.

dcoudert · 2023-11-12T11:02:33Z

The documentation don't build due to

  [sagemath_doc_html-none] OSError: /sage/src/doc/en/reference/calculus/index.rst:26: WARNING: unknown document: 'sage/calculus/expr'

tobiasdiez · 2023-11-12T14:30:11Z

But the contents of a module such as sage.all should really not depend on what distributions happen to be installed; that would be a very problematic design.

Why do you think this would be a problematic design? With your version you also have to determine which distros are installed and then import the corresponding all file.
Also what I'm proposing is very similar to the current modularization of the doctests using needs. Your approach here with special all files would correspond to extracting all doctests that need certain distro x to a new file with suffix _x.

mkoeppe · 2023-11-12T16:10:14Z

With your version you also have to determine which distros are installed and then import the corresponding all file.

No, that's not what is done. Read the documentation link I added to the ticket description.

mkoeppe · 2023-11-12T19:34:45Z

So there is a choice between the style that autopep8 uses [...] and what black uses [...]

I went with autopep8.

mkoeppe · 2023-11-13T03:58:51Z

The documentation don't build due to

  [sagemath_doc_html-none] OSError: /sage/src/doc/en/reference/calculus/index.rst:26: WARNING: unknown document: 'sage/calculus/expr'

I think I've fixed it now in 94cca3f

mantepse · 2024-04-13T18:14:00Z

I am now casting a vote of -1 on this PR.

The reason is that I do not properly understan the implications of the annotations of the form # sage_setup: distribution = sagemath-graphs in the various modules, and I think that many of them are plain wrong, at least from my personal mathematical perspective.

I think that separating math into classes like graph-theory, combinatorics, symbolics in a computer algebra system looks very strange and is bound to lead to problems in the long run, but I may be convinced otherwise.

kcrisman · 2024-04-13T18:28:12Z

I think that separating math into classes like graph-theory, combinatorics, symbolics in a computer algebra system looks very strange and is bound to lead to problems in the long run, but I may be convinced otherwise.

My understanding is that it's more about what other software is needed for the different modules (e.g., some users might not want to install Lisp to do symbolic integration via Maxima). So while there is a correlation loosely to mathematical specialties, I guess it doesn't have to be strict.

…

Message ID: ***@***.***>

mantepse · 2024-04-13T18:47:51Z

I think that separating math into classes like graph-theory, combinatorics, symbolics in a computer algebra system looks very strange and is bound to lead to problems in the long run, but I may be convinced otherwise.
My understanding is that it's more about what other software is needed for the different modules (e.g., some users might not want to install Lisp to do symbolic integration via Maxima). So while there is a correlation loosely to mathematical specialties, I guess it doesn't have to be strict.

I'm afraid I now have more questions than before, please bear with me :-)

1.) Is there an example for someone who did not want to use sage because of some dependency of the math library? Or at least a possible reason?

My fear would be that at some point there is a request not to use symbolics in some module, because Lisp is hard to install on some system.

2.) If this is about dependencies on other software, why aren't the distributions named after these dependencies? (Of course, at some point dependencies might change, for example, there might be a switch from glpk to scip.)

Before I read - by chance - distribution = sagemath-graphs somewhere, I thought one would "modularize" things like the repl, user interfaces, and perhaps some low level stuff. But it seems to me now that this is really about the modularization of the mathematics.

Also, I find it hard to believe that it is about dependencies, because the stuff in abstract_tree.py and friends has no dependencies on external software (unless you want to LaTeX them, perhaps).

kcrisman · 2024-04-13T19:11:58Z

I think that separating math into classes like graph-theory, combinatorics,

symbolics in a computer algebra system looks very strange and is bound to lead to problems in the long run, but I may be convinced otherwise. My understanding is that it's more about what other software is needed for the different modules (e.g., some users might not want to install Lisp to do symbolic integration via Maxima). So while there is a correlation loosely to mathematical specialties, I guess it doesn't have to be strict. I'm afraid I now have more questions than before, please bear with me :-)

Sorry, I've already exhausted my knowledge :-) but hopefully Matthias or others can clarify your good questions.

…

Message ID: ***@***.***>

mkoeppe · 2024-04-13T19:31:58Z

If this is about dependencies on other software, why aren't the distributions named after these dependencies?

Some are. See the required reading. Links in #29705.

mkoeppe · 2024-04-14T00:18:47Z

My fear would be that at some point there is a request not to use symbolics in some module

@mantepse Don't fear. This has been thought through carefully, and you can read about it in the Sage developer's guide.

The chain of immediate ancestors of this commit was created by cherry-picking the relevant commits that comprise sagemath#36676. Replaying all these commits (and the necessary conflict resolution) still leaves a non-empty diff when comparing 10.4.beta2 to the previous sagemath#36676 and 10.4.beta3 to that cherry-picked branch. This commit makes sure that the diff is trivial. The changes introduced here were likely introduced in conflict resolution when merging develop into sagemath#36676. I did not replay these conflict resolutions, so I do this here manually.

sagemath#36964 was inappropriately merged, since two dependencies were still disputed. This PR attempts to revert the merge. It was created by ``` git revert -m 1 6ecb1d8 ``` ### 📝 Checklist  - [x] The title is concise and informative. - [x] The description explains in detail what this PR is about. - [ ] 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 None, though it will also revert sagemath#36676 and sagemath#36951. URL: sagemath#37796 Reported by: roed314 Reviewer(s): Dima Pasechnik

culler · 2024-04-19T01:52:51Z

I think Sage should move forward with the modularization project. I vote +1 on this PR.

GMS103 · 2024-04-19T10:50:52Z

+1
Guillermo

mantepse · 2024-04-19T11:40:45Z

I posed more precise versions of the questions above in #36964 (comment). Since they have not been answered yet, and that pull request is already closed, I'll repeat them here.

1.) Is there an example for someone who did not want to use sage because of some dependency of the math library? Or at least a possible reason? @kwankyu's comment above suggests that having something in the "wrong" distribution wouldn't be a big deal. But this begs the question: who profits from cutting the math library into pieces (which look very arbitrary to me and have a curious emphasis on discrete math topics)?

My fear would be that at some point there is a request not to use symbolics in some module, because Lisp is hard to install on some system.

(I don't think this fear is unjustified: in the section of the developer guide you pointed to, I find

The imports of the symbolic functions ceil() and floor() can likely be replaced by the artithmetic functions integer_floor() and integer_ceil().

OK, so some user of that module happily replaces the two functions. Now, I come along and would like to replace some other implementation by a call to something defined in symbolics. But that would be breaking a promise to the user, so it would be really hard to justify.

In fact, this happened to me already, in some sense. I noticed a function definition in sage.modular.multiple_zeta with misleading documentation, which could be replaced by a call to code in sage.combinat. However, this is already hard to do, because it might affect performance (which is a very valid point in my opinion). I think it would be extremely bad to make it even harder.

2.) If this is about dependencies on other software, why aren't the distributions named after these dependencies? (Of course, at some point dependencies might change, for example, there might be a switch from glpk to scip.)

Before I read - by chance - distribution = sagemath-graphs somewhere, I thought one would "modularize" things like the repl, user interfaces, and perhaps some low level stuff. But it seems to me now that this is really about the modularization of the mathematics.

Also, I find it hard to believe that it is about dependencies, because the stuff in abstract_tree.py and friends has no dependencies on external software (unless you want to LaTeX them, perhaps).

NathanDunfield · 2024-04-19T14:16:27Z

1.) Is there an example for someone who did not want to use sage because of some dependency of the math library? Or at least a possible reason?

The SnapPy project is one example. This is a stand-alone Python package which gains extra functionality when used within Sage. I would much prefer we just required the (relevant parts of) the Sage math library, but we want SnapPy to be part of the broader Python ecosystem, being available on PyPI and installable via pip install snappy.

More broadly, I strongly agree with William Stein that Sage needs to be part of the broader Python ecosystem. To me, that's the main purpose of the modularization project, to fit it in better with the rest of the Scientific Python community. The correct level of granularity to choose for modularization is not an easy technical question, but I believe some level of modularization (e.g. making Lisp optional) is necessary to achieve this goal.

mantepse · 2024-04-19T16:22:35Z

1.) Is there an example for someone who did not want to use sage because of some dependency of the math library? Or at least a possible reason?

The SnapPy project is one example. This is a stand-alone Python package which gains extra functionality when used within Sage. I would much prefer we just required the (relevant parts of) the Sage math library, but we want SnapPy to be part of the broader Python ecosystem, being available on PyPI and installable via pip install snappy.

More broadly, I strongly agree with William Stein that Sage needs to be part of the broader Python ecosystem. To me, that's the main purpose of the modularization project, to fit it in better with the rest of the Scientific Python community. The correct level of granularity to choose for modularization is not an easy technical question, but I believe some level of modularization (e.g. making Lisp optional) is necessary to achieve this goal.

Yes, I agree completely. However, this means we want to distinguish between non-python dependencies, and not between subfields of mathematics, and the current pull request does not do this, as far as I can tell.

I think I would be quite OK with having, for example, sage-without-lisp, if there is a good reason for it (even though I love lisp personally, and I think that sage without will be fairly crippled).

mkoeppe · 2024-04-19T17:14:00Z

Thanks @culler and @GMS103 for the support.

This brings the tally to:

8 in favor: @mkoeppe @kwankyu @culler @jhpalmieri @kiwifb @NathanDunfield @GMS103 @roed314
5 against: @tobiasdiez @dimpase @tornaria @mantepse @orlitzky

kwankyu · 2024-04-19T22:54:02Z

My fear would be that at some point there is a request not to use symbolics in some module, because Lisp is hard to install on some system.

That should not happen. Modularization is downstream to the sage library. Yes, we are restructuring some parts of the sage library to fit with modularization. But modularization should never be an obstacle in developing the sage library. If it ever be, the sage community might drop the modularization project.

mkoeppe · 2024-04-19T23:39:21Z

I think I would be quite OK with having, for example, sage-without-lisp

That one, more or less, is the distribution package sagemath-standard-no-symbolics.

mkoeppe · 2024-04-20T19:59:45Z

1.) Is there an example for someone who did not want to use sage because of some dependency of the math library? Or at least a possible reason?

The SnapPy project is one example. This is a stand-alone Python package which gains extra functionality when used within Sage. I would much prefer we just required the (relevant parts of) the Sage math library, but we want SnapPy to be part of the broader Python ecosystem, being available on PyPI and installable via pip install snappy.

@NathanDunfield Thanks for sharing this clear example. Would you be able to estimate how much work (if any) has been necessary to make Sage an optional dependency only? (In our June 2023 discussion in https://groups.google.com/g/sage-devel/c/lb1Eq8o0a5I/m/JJQvmPzfAQAJ, you indicated "Right now, in the stand-alone apps we backstop some of Sage's functionality (e.g. arbitrary precision floats) with CyPari".)

sagemath#36964 was inappropriately merged, since two dependencies were still disputed. This PR attempts to revert the merge. It was created by ``` git revert -m 1 6ecb1d8 ``` ### 📝 Checklist  - [x] The title is concise and informative. - [x] The description explains in detail what this PR is about. - [ ] 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 None, though it will also revert sagemath#36676 and sagemath#36951. URL: sagemath#37796 Reported by: roed314 Reviewer(s): Dima Pasechnik

saraedum · 2024-04-29T12:08:12Z

This is now duplicated at #37900 to revert the revert #37796. Probably one of the two PRs should be closed @mkoeppe.

mkoeppe · 2024-04-30T00:38:57Z

Closing as this PR has been replaced by / resurrected as #37900.

….all`       Cherry-picked from sagemath#36676/sagemath#37900. ### 📝 Checklist  - [x] The title is concise and informative. - [ ] 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    URL: sagemath#37993 Reported by: Matthias Köppe Reviewer(s): John H. Palmieri, Matthias Köppe

mkoeppe added the t: refactoring label Nov 8, 2023

mkoeppe self-assigned this Nov 8, 2023

mkoeppe force-pushed the sage_all_modularization branch 3 times, most recently from a9e5ea8 to 79b1797 Compare November 8, 2023 05:59

mkoeppe changed the title ~~Restructure sage.*.all for modularization~~ Restructure sage.*.all for modularization, replace relative by absolute imports Nov 8, 2023

mkoeppe marked this pull request as ready for review November 10, 2023 03:18

mkoeppe added the s: needs review label Nov 10, 2023

mkoeppe requested review from fchapoton and dcoudert November 10, 2023 03:18

dcoudert reviewed Nov 10, 2023

View reviewed changes

tobiasdiez previously requested changes Nov 11, 2023

View reviewed changes

mkoeppe requested a review from jhpalmieri November 11, 2023 20:45

vbraun force-pushed the develop branch from 429555a to e349b00 Compare November 12, 2023 02:08

vbraun force-pushed the develop branch 2 times, most recently from 883e05f to e349b00 Compare November 12, 2023 16:25

mkoeppe force-pushed the sage_all_modularization branch from 88b91b5 to fb162de Compare November 12, 2023 19:08

vbraun force-pushed the develop branch from 23f6715 to e349b00 Compare November 12, 2023 20:04

mkoeppe force-pushed the sage_all_modularization branch from 0f5ef2f to d62bed8 Compare November 12, 2023 21:38

mkoeppe reopened this Apr 13, 2024

mkoeppe added the s: needs review label Apr 19, 2024

This was referenced Apr 29, 2024

Restructure sage.*.all for modularization, replace relative by absolute imports #37900

Open

Add # sage_setup: distribution directives to all files #37901

Open

mkoeppe closed this Apr 30, 2024

github-actions bot removed the s: needs review label Apr 30, 2024

		from sage.misc.lazy_import import lazy_import
		lazy_import('sage.algebras.steenrod.steenrod_algebra', ['SteenrodAlgebra', 'Sq'])

Restructure sage.*.all for modularization, replace relative by absolute imports #36676

Restructure sage.*.all for modularization, replace relative by absolute imports #36676

Conversation

mkoeppe commented Nov 8, 2023 • edited Loading

📝 Checklist

⌛ Dependencies

dcoudert left a comment

Choose a reason for hiding this comment

mkoeppe commented Nov 10, 2023

tobiasdiez left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mkoeppe Nov 12, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mkoeppe commented Nov 11, 2023 • edited Loading

mkoeppe commented Nov 11, 2023 • edited Loading

tobiasdiez commented Nov 11, 2023

mkoeppe commented Nov 11, 2023 • edited Loading

dcoudert commented Nov 12, 2023

tobiasdiez commented Nov 12, 2023

mkoeppe commented Nov 12, 2023

mkoeppe commented Nov 12, 2023

mkoeppe commented Nov 13, 2023

mantepse commented Apr 13, 2024

kcrisman commented Apr 13, 2024 via email

mantepse commented Apr 13, 2024

kcrisman commented Apr 13, 2024 via email

mkoeppe commented Apr 13, 2024

mkoeppe commented Apr 14, 2024

culler commented Apr 19, 2024

GMS103 commented Apr 19, 2024

mantepse commented Apr 19, 2024

NathanDunfield commented Apr 19, 2024

mantepse commented Apr 19, 2024

mkoeppe commented Apr 19, 2024

kwankyu commented Apr 19, 2024 • edited Loading

mkoeppe commented Apr 19, 2024

mkoeppe commented Apr 20, 2024

saraedum commented Apr 29, 2024

mkoeppe commented Apr 30, 2024

Restructure `sage.*.all` for modularization, replace relative by absolute imports #36676

Restructure `sage.*.all` for modularization, replace relative by absolute imports #36676

mkoeppe commented Nov 8, 2023 •

edited

Loading

mkoeppe Nov 12, 2023 •

edited

Loading

mkoeppe commented Nov 11, 2023 •

edited

Loading

mkoeppe commented Nov 11, 2023 •

edited

Loading

mkoeppe commented Nov 11, 2023 •

edited

Loading

kwankyu commented Apr 19, 2024 •

edited

Loading