Add a distribution package test for aioax25 #123
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Different distribution packages store their metadata in different ways which can be hard to compare directly, most notably due to different versions of the core metadata standard. For example, the Requires and Requires-Dist headers are equivalent-ish in the sense that they both express dependencies, but technically any recent core metadata listing such in a PKG-INFO file could use either one (or maybe even a mix of both, not that I've seen that). This makes it difficult to compare the expected metadata for a package, obtained from the package itself, with the metadata generated from setuptools-pyproject-migration, since they could adhere to different versions of the core metadata standard and use different sets of headers in other ways. After lots of false starts, I decided that the most practical way to do that comparison is to parse the core metadata (PKG-INFO or whatever) back into some canonical format, such as the StandardMetadata object from pyproject-metadata. But pyproject-metadata doesn't allow parsing its RFC822Message class back into a StandardMetadata, it only goes the other way. So I wrote us a function to do that conversion, which is what I'm adding here. I haven't extensively tested this function, and it could very well have bugs - handling all the different versions of the core metadata standard is a little complex. But it seems to work well enough for the moment. We can always add more tests (ah, the irony of having to test the test support code) and fix issues that may show up in the future.
This commit does a pretty major refactoring of the distribution package test support code. The main change is to remove all test-specific state and state-changing operations from the DistributionPackage class and put them in DistributionPackagePreparation, so now the workflow is that we use a list of DistributionPackage objects to parametrize the tests, and in each test we "convert" the DistributionPackage to an instance of DistributionPackagePreparation which is then used and mutated as needed for the test. Without doing this, it wouldn't really make sense to use DistributionPackage instances to parametrize tests because they would change each time they were used. A big part of that change involved creating a hierarchy of DistributionPackagePreparation classes, because each type of DistributionPackage needs its own DistributionPackagePreparation subclass to store relevant state. That change turned out to be a very complex one, and while working on it I also made some other changes that turned out to be pretty difficult to disentangle afterwards. So I'm leaving these additional changes as part of this commit: - Improved use of cached properties and function return values to avoid downloading or extracting the same files more than once - Better organization of the code that computes core reference metadata so that now each possible metadata source (wheel file or metadata file from PyPI) is its own separate method
This will enable running distribution package tests on packages that don't provide wheels.
In this commit I'm introducing a new flag that will cause the root directory of a distribution package project to be added to sys.path while that package is being tested. Some packages expect their own code to be available when running their setup.py, and this accounts for that requirement.
This package exposed an issue that arises where the long description is only given in setup.py, not setup.cfg, so it's a useful test. Plus it is maintained by Stuart.
This change allows using custom logic to compare individual fields, which is occasionally necessary (e.g. to ignore the order of a list). It also allows skipping the fields related to entry points which cannot be computed from the core metadata.
sjlongland
approved these changes
Dec 4, 2023
|
The I doubt that this is going to be packaged by any Linux distributions though. If that winds up happening we can cross the proverbial bridge when we come to it. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is the long-awaited (by me, probably not anyone else) implementation of a test of aioax25, to confirm that setuptools-pyproject-migration produces a
pyproject.tomlfile that generates the same core metadata as the project's ownsetup.pyfile. In order to get this working, I kind of had to rewrite the distribution package test support code. Details are in the commit messages, but basically:setup.pyDistributionPackage/DistributionPackagePreparationclass hierarchies so thatDistributionPackagewould not have any state that needs to be changed during testingFortunately, after all that work, the new test passes 😄
Closes #105