Replace relative imports by absolute ones in sage.{algebras,arith,categories,cpython,data_structures,misc,modular,rings,sat,symbolic}

[mkoeppe]

Final chunk of the cherry-pick from #35095 for #36228, see also #36572 (comment)

This PR overlaps with #36572, #36588, #36589, but it does not touch .all* files (no changes there are needed for #36228), thus avoiding conflicts with #35095 (see also #36524 (comment))

📝 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

[tobiasdiez]

So you don't want to resolve merge conflicts with your PR, but instead force me to do it?!

[mkoeppe]

So you don't want to resolve merge conflicts with your PR, but instead force me to do it?!

Tobias, I know that you know all of the following -- but I'll explain it for the audience:
This is a "common denominator PR", which I prepared carefully so that it avoids conflicts.
Indeed, I have just rebased your #36572, #36588, #36589 on top of it, simply by typing gh pr checkout 36572, then git rebase absolute_cimport_sage_arith, then git push --force. The rebase happened automatically, with no need for conflict resolution.

[dcoudert]

LGTM and passes tests on Fedora 35.

[tobiasdiez]

So you don't want to resolve merge conflicts with your PR, but instead force me to do it?!

Tobias, I know that you know all of the following -- but I'll explain it for the audience: This is a "common denominator PR", which I prepared carefully so that it avoids conflicts. Indeed, I have just rebased your #36572, #36588, #36589 on top of it, simply by typing gh pr checkout 36572, then git rebase absolute_cimport_sage_arith, then git push --force. The rebase happened automatically, with no need for conflict resolution.

And how is that helping with these PRs being in conflict with #35095? You have to resolve these conflicts eventually so why not now?

[dcoudert]

I'm not setting this to positive review yet as the priority is to clarify the situation with respect to #36572, #36588, and #36589.

[mkoeppe]

Tobias, again you are abusing your privileges as a member of the Triage group.

[jhpalmieri]

I'm a little puzzled by the goal here. If I do git grep 'from [.]' src/sage/categories, I get some hits (in algebra_ideals.py, for instance), so you have not replaced all relative imports. As far as I can tell, you have not touched any all.py files, which are filled with relative imports. Can you clarify?

[jhpalmieri]

In the meantime, is the main disagreement about which changes get merged first? The other branches have been rebased on top of this one, so why not proceed with this one?

[tobiasdiez]

Tobias, again you are abusing your privileges as a member of the Triage group.

Sorry, just clicked the wrong button. Didn't meant to close the pr

[mkoeppe]

I'm a little puzzled by the goal here. If I do git grep 'from [.]' src/sage/categories, I get some hits (in algebra_ideals.py, for instance), so you have not replaced all relative imports. As far as I can tell, you have not touched any all.py files, which are filled with relative imports. Can you clarify?

Only relative imports and cimports in Cython files are relevant for the purpose of resolving the problems of current Cython 3.0.x with namespace packages. I made these changes back in September or so in #35095 because of an acute need for this in the modularization. I opened PR #36228 for the task of upstreaming this into mainline Sage.

Changes to all.py files are irrelevant for the Cython issue. Moreover, in #35095, many all.py files are completely restructured for modularization purposes, so changes there have to be done separately from changes in Sage develop.

This PR is a cherry-pick from my branch in #35095, the three commits indicated #36572 (comment), with any conflicts in cherry picking resolved to "no change".

[jhpalmieri]

I'm a little puzzled by the goal here. If I do git grep 'from [.]' src/sage/categories, I get some hits (in algebra_ideals.py, for instance), so you have not replaced all relative imports. As far as I can tell, you have not touched any all.py files, which are filled with relative imports. Can you clarify?

Only relative imports and cimports in Cython files are relevant for the purpose of resolving the problems of current Cython 3.0.x with namespace packages. I made these changes back in September or so in #35095 because of an acute need for this in the modularization. I opened PR #36228 for the task of upstreaming this into mainline Sage.

Changes to all.py files are irrelevant for the Cython issue. Moreover, in #35095, many all.py files are completely restructured for modularization purposes, so changes there have to be done separately from changes in Sage develop.

This PR is a cherry-pick from my branch in #35095, the three commits indicated #36572 (comment), with any conflicts in cherry picking resolved to "no change".

Got it, thank you. The changes look good to me, too, so I will echo the approval from @dcoudert.

[tobiasdiez]

In the meantime, is the main disagreement about which changes get merged first? The other branches have been rebased on top of this one, so why not proceed with this one?

Of course, I can always open a PR that contains various subsets of changes proposed in other PRs. But there is only value in doing this if there is a problem with the original PRs (otherwise these other PRs could be directly merged). The only problem that has been pointed out so far is that Matthias doesn't want to resolve the merge conflicts in 'all.py' files introduced in these PRs. But someone has to resolve this conflicts at some point, so why not do it now?

[jhpalmieri]

In the meantime, is the main disagreement about which changes get merged first? The other branches have been rebased on top of this one, so why not proceed with this one?

Of course, I can always open a PR that contains various subsets of changes proposed in other PRs. But there is only value in doing this if there is a problem with the original PRs (otherwise these other PRs could be directly merged). The only problem that has been pointed out so far is that Matthias doesn't want to resolve the merge conflicts in 'all.py' files introduced in these PRs. But someone has to resolve this conflicts at some point, so why not do it now?

Aren't the only existing conflicts with #35095? Since Matthias is responsible for that branch, he is capable of handling any merge conflicts there when he is ready to do so. I would not be surprised, though, if I don't have the full picture, so please explain what I might be missing.

[tobiasdiez]

In the meantime, is the main disagreement about which changes get merged first? The other branches have been rebased on top of this one, so why not proceed with this one?

Of course, I can always open a PR that contains various subsets of changes proposed in other PRs. But there is only value in doing this if there is a problem with the original PRs (otherwise these other PRs could be directly merged). The only problem that has been pointed out so far is that Matthias doesn't want to resolve the merge conflicts in 'all.py' files introduced in these PRs. But someone has to resolve this conflicts at some point, so why not do it now?

Aren't the only existing conflicts with #35095?

Yes, that's why I'm also not understanding the purpose of this PR here.

Matthias, could you please explain to us your envisioned strategy to resolve the conflicts between #35095 and my PRs, and how this PR here is needed for this.

As an explanation of why I'm so negative about this PR here, is that I'm seeing it as being part of the following 'strategy' (in fact, the only reason that I can see of why Matthias opened this PR is to exactly enable this strategy):

1. Create a PR (namely this one here) that contains the changes from my PRs that are needed for Modularization of sagelib: Distributions 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} #35095.
2. Block/ignore my PRs (because they are now no longer relevant for what Matthias is doing)
3. In the meantime, propose the restructured all.py files (as announced at Compile everything with meson #36524 (comment)). If this gets merged before my PRs, I'm the one that has to resolve the merge conflicts.

[mkoeppe]

Matthias, could you please explain to us your envisioned strategy to resolve the conflicts

I think this is a gratuitous request for information. It has been explained already: It is a "common denominator PR".

This is a standard maintainer technique for achieving development velocity. By merging it in "develop", it reduces the size of diffs of the related PRs, thus facilitating review of all of these PRs.

[jhpalmieri]

In the meantime, is the main disagreement about which changes get merged first? The other branches have been rebased on top of this one, so why not proceed with this one?

Of course, I can always open a PR that contains various subsets of changes proposed in other PRs. But there is only value in doing this if there is a problem with the original PRs (otherwise these other PRs could be directly merged). The only problem that has been pointed out so far is that Matthias doesn't want to resolve the merge conflicts in 'all.py' files introduced in these PRs. But someone has to resolve this conflicts at some point, so why not do it now?

Aren't the only existing conflicts with #35095?

Yes, that's why I'm also not understanding the purpose of this PR here.

Matthias, could you please explain to us your envisioned strategy to resolve the conflicts between #35095 and my PRs, and how this PR here is needed for this.

As an explanation of why I'm so negative about this PR here, is that I'm seeing it as being part of the following 'strategy' (in fact, the only reason that I can see of why Matthias opened this PR is to exactly enable this strategy):

1. Create a PR (namely this one here) that contains the changes from my PRs that are needed for [Modularization of sagelib: Distributions 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} #35095](https://github.com/sagemath/sage/pull/35095).

2. Block/ignore my PRs (because they are now no longer relevant for what Matthias is doing)

If they directly conflict with what he's doing, that's something that needs to be resolved. If they can be merged independently of what he's doing, then others can approve them and they can get merged. When you say that they are no longer relevant, it sounds like we're in the latter situation.

3. In the meantime, propose the restructured `all.py` files (as announced at [Compile everything with meson #36524 (comment)](https://github.com/sagemath/sage/pull/36524#issuecomment-1792680978)). If this gets merged before my PRs, I'm the one that has to resolve the merge conflicts.

When the time comes, I am willing to help resolve the merge conflicts. Ping me.

[mkoeppe]

It's all green, so let's get this in

[mkoeppe]

Thanks!

[tobiasdiez]

That is only one of the points in #36666 (comment).

[mkoeppe]

That is only one of the points in #36666 (comment).

Would you clarify for us: Do you mean that you are also doubling down on your false claim of authorship (the 2nd point in your list)?

[mkoeppe]

That is only one of the points in #36666 (comment).

Would you clarify for us: Do you mean that you are also doubling down on your false claim of authorship (the 2nd point in your list)?

@tobiasdiez My question does require an answer.

[tobiasdiez]

That is only one of the points in #36666 (comment).

Would you clarify for us: Do you mean that you are also doubling down on your false claim of authorship (the 2nd point in your list)?

@tobiasdiez My question does require an answer.

Sorry, I read that as a rhetoric question. We both know that I didn't authored these commits, and I never claimed I did. Your little rebase experiment should have convinced you that (all?/most of?) your changes here were already contained in my PRs. So I think a bit of attribution does not hurt.

[mkoeppe]

That is only one of the points in #36666 (comment).

Would you clarify for us: Do you mean that you are also doubling down on your false claim of authorship (the 2nd point in your list)?

@tobiasdiez My question does require an answer.

Sorry, I read that as a rhetoric question. We both know that I didn't authored these commits,

Yes, we both do know that.
The problem is that you have tried to mislead the public about it.

and I never claimed I did.

As part of setting the status back to "needs work", you demanded in #36666 (comment):

Add me as coauthor for proper attribution

Using the word "proper" here means that you were accusing me of improperly withholding attribution.

Your little rebase experiment

That's patronizing language, unwelcome here.

should have convinced you that (all?/most of?) your changes here were already contained in my PRs. So I think a bit of attribution does not hurt.

Here again you are writing to mislead the public.

When you opened #36572 on Oct 29, the same day I informed you in #36572 (comment) that I made the changes to the Cython files already in #35095 for the whole Sage library. (On Oct 30, I added the precise commits to this comment for reference.)

On Oct 30, nevertheless you opened #36588 and #36589, which overlap with my changes. (Apparently you were unconcerned about attribution at that time!)

On Nov 3, I informed you in #36588 (comment) and #36589 (comment) that "The only thing that is needed to solve the problem with Cython is to take care of relative cimports, not imports. Doing this in one PR creates lots of gratuitous merge conflicts with #35095." (Note that I did not demand any changes.)

You responded in #36588 (comment): "my main motivation is making it work with pytest. For this the normal imports have to be changed as well." (You seemed unconcerned about my workload of resolving the resulting merge conflicts: "I'm sorry for the merge conflicts, but they should be easy to resolve.")

I opened the present PR, which is cherry-picked carefully from #35095 and does not create merge conflicts. The rest can be read above.

[github-actions]

Documentation preview for this PR (built with commit b2222c3; changes) is ready! 🎉

[mkoeppe]

Regarding point 4 of #36666 (comment),

Revert your recent force pushes to my PRs

... last week Tobias undid the rebase of the branches of #36572, #36588, #36589, and today his original branches have been merged into develop.