Yeah; that makes sense—since your tooling (PBR, but also true of the popular setuptools-scm
) not only ensures your sdists include everything checked into your repo, minus VCS-specific files, and also bakes in additional metadata, your sdists are indeed more complete representations of your source than a straight tarball of your worktree. Whereas in our (Spyder project) case, we still rely on manual MANIFEST.in
maintenance but also maintain our own tooling (LogHub) that takes care of things like updating the CHANGELOG and AUTHORS from the GitHub issues, PRs and contributors, which is all checked into source control.
I’ve been suggesting switching to setuptools_scm
for automatic version and manifest management, which would result in a setup very similar to yours, but there’s some amount of institutional inertia and reluctance to “fix what ain’t broke” and a number of places that Spyder itself uses the version information that would need to change, as well as higher short-term priorities (e.g. modernizing our packaging config/infra and CI setup) to spend our limited resources and change budget on.
This is our standard practice as well in the Spyder project, where we not only have tests
be a subpackage but have tests
subdirectories for every directory that contain tests for the code in each module within, i.e.:
_ spyder
|__ spam
|__ eggs
|__ ham
| |__ foo
| |__ bar
| |__ tests
| |__ test_foo
| |__ test_bar
|__ tests
|__ test_spam
|__ test_eggs
As some background, Spyder is a 15 year old project originally developed by a scientist with limited programming experience, and the original “tests” were just regular functions and function/method calls in the if __name__ == "__main__"
blocks of the code under test, so this was a natural outgrowth of that.
In some other (typically smaller) projects I’m involved in, we use the src
layout and locate our tests outside the package, organized by type (unit, integration, functional) and run from the source against the installed wheel.
I was actually completely unaware of that; for reference, could you point me to where that is mentioned?
Using _
is fine; PEP 685 doesn’t change that. _
is the most common non-alphanumeric character used in extras names, and being perfectly okay under the PEP 508 rules adopted by PEP 685. It’ll automatically get normalized to -
via PEP 503 normalization when written out to core metadata, and consuming tools will also normalize it when comparing, so it doesn’t really make any practical difference (except in one specific scenario, but changing it on your end now won’t help that at all).
If you do make a change, you might want to consider a test
extra, and a dev
extra that includes test
plus all your development dependencies, at least in terms of standard convention. But no need unless you want to, at least until it is more standardized, though nominally the core metadata spec does reserve the test
extra for running tests:
Two feature names test and doc are reserved to mark dependencies that are needed for running automated tests and generating documentation, respectively.