Let's get it in.

Rebase onto develop please?

Rebased.

Both choices for the metadata (./bootstrap or file=[...]) reference the build tree from src and therefore look comparably bad to me w.r.t. maintaining library/distro separation. But we also don't need to redesign it right now. Does this cause problems for anyone? If not, this is standard python packaging churn and is fine with me.

Both choices for the metadata (./bootstrap or file=[...]) reference the build tree from src

Yes, but bootstrap only runs at ... bootstrapping time, so it is a "repository concern" only and not a "distribution concern" if that makes sense. After running bootstrap, each subdirectory in pkgs is a self-contained source directory of a Python distribution.

Also, in PRs such as the following, I make less code dependent on the file layout within build/pkgs. So poking into there directly from the pyproject.toml would run counter to this work.

• Refactor bootstrap-conda, m4/sage_spkg_collect.m4 through sage-package; handle dependencies_build #36740

Does this cause problems for anyone?

No, I wouldn't know how it could.

Let's get this in please.

Both choices for the metadata (./bootstrap or file=[...]) reference the build tree from src and therefore look comparably bad to me w.r.t. maintaining library/distro separation. But we also don't need to redesign it right now.

@kwankyu Sorry, forgot to mention that this suggestion was implemented in #36982.

To not hold up this PR here until #36982 is merged, I would be fine for now with putting the dynamically created information in file that is generated during bootstrap and included in pyproject.toml via the file tag.

It works well. LGTM.

There's now a conflicting proposal in #36982, both are probably headed to the dispute pile.

To not hold up this PR here until #36982 is merged, I would be fine for now with putting the dynamically created information in file that is generated during bootstrap and included in pyproject.toml via the file tag.

This PR does not have to wait for any such innovations.

Merge conflict

On Thursday, assuming the vote on sage-devel continues the way it currently looks, you will be able to try to persuade other Sage developers of your perspective and use the disputed PR mechanism. You should view the setting of this back to "positive review" as correcting the mislabeling that occurred when that label was removed. (Once it received the original positive review, the undoing of that label was inappropriate in this case, so the Sage Code of Conduct Committee is restoring its status.)

What about

* [sagemath-standard: include sage_setup in sdist #37287 (comment)](https://github.com/sagemath/sage/pull/37287#issuecomment-1954881868)

* [Readd init files #36753 (comment)](https://github.com/sagemath/sage/pull/36753#issuecomment-1952569267)

* etc.

Once a ticket has a "disputed" label, its review status should not be changed. (This policy was communicated only to a few developers, not widely as it should have been.) On those PRs, the ticket was labeled as disputed, then the ticket was given a positive review, and then the positive review was undone to comply with the policy to keep the labels as they were when it was tagged as disputed.

Once a ticket has a "disputed" label, its review status should not be changed. (This policy was communicated only to a few developers, not widely as it should have been.) On those PRs, the ticket was labeled as disputed, then the ticket was given a positive review, and then the positive review was undone to comply with the policy to keep the labels as they were when it was tagged as disputed.

I added the disputed label myself (see #37287 (comment)) just to indicate a technical concern by someone else. I did not mean what you say above, in fact you'll see I added needs review at the same time I added the disputed label.

In this case, there's a competing PR at [...]

@orlitzky Elsewhere, I have explained how pointing to such so-called competing PRs presents a false dichotomy. There's nothing in this PR here that would preclude making design changes as a follow up. In the meantime, this PR is ready (and has been, for months) and is an obvious and clear improvement.

In this case, there's a competing PR at [...]

@orlitzky Elsewhere, I have explained how pointing to such so-called competing PRs presents a false dichotomy. There's nothing in this PR here that would preclude making design changes as a follow up. In the meantime, this PR is ready (and has been, for months) and is an obvious and clear improvement.

Yes, but in certain cases you're asking for commit wars to replace the label wars and that will waste a lot more of everyone's time.

@orlitzky Yes, I can also imagine many more ways how bad actors can obstruct and disrupt development.

But this should not have a bearing on how we do Sage development. Our standard of review is clear: Is it an improvement? Is it ready? Then we merge it.

I'm posting to record a vote of -1 on behalf of Tobias Diez.

+1 from me.

@kcrisman Responding to your suggestion in https://groups.google.com/g/sage-devel/c/IgBYUJl33SQ/m/ciVrZ7x0AQAJ

I am the main author of this PR. I confirm that I am +1 on merging its current version.

This is a properly focused PR which makes a routine change, modernizing the Python metadata format. It is consistent with what we already have in the Sage repository (#36951 (comment)).
And I have contributed similar changes to numerous other projects, including:

• pyproject.toml: Move metadata here from setup.cfg pytest-dev/pytest-mock#410,
• src/py/pyproject.toml: Move metadata here from setup.cfg pyodide/pyodide#4472,
• pyproject.toml: Move metadata and setuptools config here from setup.cfg pytest-dev/pytest-xdist#1020,
• Modernize project metadata cypari2#158,
• Declare build deps in pyproject.toml fplll/fpylll#258,
• Switch from distutils to setuptools, move metadata to pyproject.toml polymake/JuPyMake#2,
• Migrate metadata from setup.py, setup.cfg to pyproject.toml cvxpy/cvxpy#2276,
• Add pyproject.toml, remove Cython from setup_requires, install_requires cysignals#177
• Modernize Python metadata Mathics3/Mathics3-scanner#58
• pyproject.toml: Move metadata, setuptools config here from setup.cfg ipython/ipython#14326, pyproject.toml (project.entrypoints, project.scripts): Define here ipython/ipython#14340

As explained in #36951 (comment) and before, opening a "competing PR" of vastly larger scope (#36982) and using it to argue that the present PR should not be merged is a deliberate use of a fallacious dichotomy -- and just one of several manipulation techniques on display here.

Still +1 from me.

Based on @kwankyu's suggestion and discussion by the new Code of Conduct Committee, I'm setting this ticket to Needs Review so that all the disputed tickets start with a clean slate prior to being update based on voting. Starting at midnight US/Pacific time tonight anyone involved should feel free to set the status to positive review or needs review in accordance with the new policy.

I'm counting:

• in favor: @mkoeppe @kwankyu @kiwifb
• against: Tobias Diez

Thus setting to positive review.

You missed my concerns #36951 (comment)

I'm -1 on this for several reasons:

• I think moving to pyproject.toml is a good idea, as it's the modern way python packages work; however, it should be pyproject.toml and not pyproject.toml.m4.
• You need to fix build dependencies. Right now you require a lot of dependencies just to create a sdist.
• This conflicts with other disputed PRs and I believe the way to move forward is to come together and figure out a reasonable compromise between all the different positions

You missed my concerns #36951 (comment)

No, I didn't.

I'm -1 on this for several reasons:

• I think moving to pyproject.toml is a good idea, as it's the modern way python packages work; however, it should be pyproject.toml and not pyproject.toml.m4.

Scope, Gonzalo, scope. As explained in #36951 (comment)

• You need to fix build dependencies. Right now you require a lot of dependencies just to create a sdist.

No, I don't to fix anything. I've explained it to you already. That's simply not how setuptools works.

• This conflicts with other disputed PRs

No, it does not.

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

+1 from me.

Thanks, John.

The changes from this PR are now at #37902 which reverts the revert from #37796.