Bump minimal flit version everywhere

[DimitriPapadopoulos]

Basic support for PEP 639 requires flit 3.11.

The minimal version is specified in two different places, only the first one had been updated:

wheel/pyproject.toml

Lines 1 to 2 in 56223f6

	[build-system]
	requires = ["flit_core >=3.11,<4"]

wheel/pyproject.toml

Lines 139 to 140 in 56223f6

	[tool.tox.env.pkg]
	deps = ["build", "flit >= 3.8"]

I wonder whether a single occurrence of the minimal version is possible... It appears it should be possible to specify all dependencies in a single place. Modernize dependency handling to achieve that.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 55.14%. Comparing base (56223f6) to head (1ed9378).
⚠️ Report is 2 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #680   +/-   ##
=======================================
  Coverage   55.14%   55.14%           
=======================================
  Files          15       15           
  Lines        1206     1206           
=======================================
  Hits          665      665           
  Misses        541      541           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[agronholm]

I'm not convinced yet.

[DimitriPapadopoulos]

I'm not totally convinced myself. Rather, I am convinced that dependency groups are the proper way to define dependencies nowadays, but unsure that it is feasible to avoid specifying the build system both at the top and the bottom of pyproject.toml — which would probably be a tox shortcoming.

The latter does require more investigation, I'm sorry about that.

[agronholm]

I'm not totally convinced myself. Rather, I am convinced that dependency groups are the proper way to define dependencies nowadays, but unsure that it is feasible to avoid specifying the build system both at the top and the bottom of pyproject.toml — which would probably be a tox shortcoming.

The latter does require more investigation, I'm sorry about that.

The dependencies in build-system are installed in isolation just for the build process. They're not made available in the test environment.

[DimitriPapadopoulos]

I understand this is all supposed to work automatically. From the tox documentation:

Packaging

tox builds projects in a PEP 518 compatible virtual environment and communicates with the build backend according to the interface defined in PEP 517 and PEP 660. To define package build dependencies and specify the build backend to use, create a pyproject.toml at the root of the project. For example to use hatch:

[build-system]
build-backend = "hatchling.build"
requires = ["hatchling>=0.22", "hatch-vcs>=0.2"]

Build environments

tox uses a virtual environment for building, whose name depends on the artifact type:

• For source distributions: the package_env (default .pkg)
• For wheels: the wheel_build_env (default .pkg-<impl><version>, e.g. .pkg-cpython313)
• For sdist-wheel: uses two environments — the package_env for building the sdist, and the wheel_build_env (default .pkg-<impl><version>) for building the wheel from the extracted sdist

For pure Python projects (no C extensions), set wheel_build_env to the same value as package_env. This way the wheel is built once and reused for all tox environments:
``toml
[env_run_base]
package = "wheel"
wheel_build_env = ".pkg"

At least, I understand this should work, as it lets build handle the [build-system] automatically:

python -m build --sdist --no-isolation

I guess this doesn't work, as it requires the flit CLI:

python -m flit build --format=sdist

I will test all that more thoroughly, but need to understand what tests/test_sdist.py does. What exactly does it try to compare? With and without PEP 517 isolation? python -m build vs. python -m flit build? And why is that test important?

[agronholm]

I understand this is all supposed to work automatically. From the tox documentation:

Packaging

tox builds projects in a PEP 518 compatible virtual environment and communicates with the build backend according to the interface defined in PEP 517 and PEP 660. To define package build dependencies and specify the build backend to use, create a pyproject.toml at the root of the project. For example to use hatch:

[build-system]
build-backend = "hatchling.build"
requires = ["hatchling>=0.22", "hatch-vcs>=0.2"]

Build environments

tox uses a virtual environment for building, whose name depends on the artifact type:

• For source distributions: the package_env (default .pkg)
• For wheels: the wheel_build_env (default .pkg-<impl><version>, e.g. .pkg-cpython313)
• For sdist-wheel: uses two environments — the package_env for building the sdist, and the wheel_build_env (default .pkg-<impl><version>) for building the wheel from the extracted sdist

For pure Python projects (no C extensions), set wheel_build_env to the same value as package_env. This way the wheel is built once and reused for all tox environments:
``toml
[env_run_base]
package = "wheel"
wheel_build_env = ".pkg"

At least, I understand this should work, as it lets build handle the [build-system] automatically:

python -m build --sdist --no-isolation

I guess this doesn't work, as it requires the flit CLI:

python -m flit build --format=sdist

I will test all that more thoroughly, but need to understand what tests/test_sdist.py does. What exactly does it try to compare? With and without PEP 517 isolation? python -m build vs. python -m flit build? And why is that test important?

This test was contributed to the project after a failed release when setuptools was replaced with flit as the build backand, and the sdist didn't contain the expected files. I wouldn't characterize this as an important test anymore, but I have no good reason to toss it away either. I must ask, why are you so invested in making these little changes to this project?

[DimitriPapadopoulos]

To be honest, that's because I am fed up with the cacophony that characterizes Python development tools, at odds with the initial simplicity of the language itself. The whole ecosystem reminds of Perl ("There Is More Than One Way To Do It"). That's especially true nowadays when comparing Python to more recent languages like Go and Rust. Consistency and homogeneity, especially in the Python development tools themselves, would probably help everyone package Python software in a clean, standard and maintainable way.

[agronholm]

Rust and Go have the advantage of hindsight, and Python had to solve problems these languages never had, and still don't have. That said, I don't see how the changes in this PR help with this at all. These changes only deal with how the wheel project itself is developed, and the requires = ["tox>=4.22"] change is the only thing here that at least marginally improves things.

[DimitriPapadopoulos]

Well, I turned to the build and packaging tools themselves to understand how to build and package my own software, because the documentation was terrible. I found the gradual migration from setup.py to setup.cfg to pyproject.toml perhaps worse than the Python 2 to 3 transition. Any way, it's almost done now, and the documentation has improved much. But I would still expect the development of these tools to be as exemplary as possible, sticking to standards as much as possible.

I can revert though, and just bump the flit version 3.8 → 3.11.

[agronholm]

Well, I turned to the build and packaging tools themselves to understand how to build and package my own software, because the documentation was terrible. I found the gradual migration from setup.py to setup.cfg to pyproject.toml perhaps worse than the Python 2 to 3 transition. Any way, it's almost done now, and the documentation has improved much. But I would still expect the development of these tools to be as exemplary as possible, sticking to standards as much as possible.

If you find this project not following one of the packaging standards, feel free to link to the document of said standard.

I can revert though, and just bump the flit version 3.8 → 3.11.

Yes, please do that.

[henryiii]

By the way, check-sdist (my package) compares the git contents (similar to flit) with the SDist produced using standards (build, uv build, etc). You could use that instead of running flit and build and comparing them.

[DimitriPapadopoulos]

Done. @henryiii A few additional questions if you don't mind:

• I understand test_sdist.py should not be skipped, so how about removing pytest.importorskip?
  

  wheel/tests/test_sdist.py

  Lines 9 to 10 in a99cdd5

  	pytest.importorskip("flit")
  	pytest.importorskip("build")

• The pkg environment just builds and tests two sdists, doesn't it? Can I add package = "skip", as in the previous lint environment?
  

  wheel/pyproject.toml

  Line 131 in a99cdd5

  package = "skip"

[henryiii]

test_sdist.py is completely separate from the rest of the test suite. As it stands now, running just this file doesn't require the package installed (which is why package = "skip" would work), and in the normal tests, it is attempted but skipped since flit and build are not installed. If wheel was imported in that file, then it would be no instead.

So to answer your first question technically, no, section question, yes. But that's not necessarily the best direction, just the technical correct answer.

IMHO, test_sdist.py really shouldn't be part of the normal test suite. Its requirements and actions are completely different. Downstream distributors, for example, never want to run test_sdist.py, since they don't care about building wheel's SDist; they don't build that and don't care about the source to PyPI packaging steps at all. To me, this is a pre-commit style check (and why I suggested check-sdist), but if that wasn't used, it still could technically be pulled out into a custom helper script or similar, rather than being in the test suite like it is.

Though, I have pretty much the same sort of a special test file in scikit-build-core, slightly different usage (since I use check-sdist there), so maybe I'm not one to talk. :)

[DimitriPapadopoulos]

I've reverted to bumping flit — just added the couple cleanups discussed above.

Moving the sdist check outside the tox tests can be done in a different PR. I'm still unsure what comparing the result of the following commands is about exactly, and whether check-sdist is equivalent:

python -m build --sdist --no-isolation

python -m flit build --format=sdist

I understand #501 introduced tests/test_sdist.py to make sure the flit backend doesn't modify the previous build based on setuptoools. Now that flit has been in use for 3 years, does this test still make sense?

[agronholm]

I've reverted to bumping flit — just added the couple cleanups discussed above.

Moving the sdist check outside the tox tests can be done in a different PR. I'm still unsure what comparing the result of the following commands is about exactly, and whether check-sdist is equivalent:

python -m build --sdist --no-isolation

python -m flit build --format=sdist

I understand #501 introduced tests/test_sdist.py to make sure the flit backend doesn't modify the previous build based on setuptoools. Now that flit has been in use for 3 years, does this test still make sense?

Probably not.

[agronholm]

If you want to remove that test, I'm not against it.

[DimitriPapadopoulos]

Fine. It's now clear to me this was as a one-shot test to make sure setuptools and flit create the same sdist. It should have been removed after testing or merging #501, it's essentially a no-op nowadays.

[henryiii]

flit build will ask git what files to include, while the hook for standards based builders does not. It's been a pain point of mine against flit-core for a while; someone who runs flit locally gets a working distribution and wheel, but then if they use build or uv build to ship files (or something like hyena's action), suddenly stuff is missing, because it uses different rules.

I've opened a PR to use that instead. I'd recommend not touching test_sdist.py for this PR.

[agronholm]

Okay, it seems like all the proposed improvements are in. I added the one missing thing, the minimum tox version requirement in the tox configuration, so we're all set here. Thanks for getting the ball rolling @DimitriPapadopoulos . I'm closing this PR as there's nothing left to be done.