Add framework for enumerating installed Python files#728
Open
Add framework for enumerating installed Python files#728
Conversation
cottsay
force-pushed
the
cottsay/pydist
branch
2 times, most recently
from
a5f80e3 to
61f6e8d
Compare
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #728 +/- ##
==========================================
+ Coverage 87.00% 87.26% +0.26%
==========================================
Files 69 70 +1
Lines 4093 4265 +172
Branches 707 752 +45
==========================================
+ Hits 3561 3722 +161
- Misses 421 429 +8
- Partials 111 114 +3 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
cottsay
force-pushed
the
cottsay/pydist
branch
6 times, most recently
from
8ea0acb to
0e441a9
Compare
In order for colcon to consume wheels produced by PEP 517 build backends, we'll need to explicitly uninstall existing Python packages from the install space. This primarily stems from the differences in metadata representation, where the previous setuptools-only Python build mechanisms wrote `.egg-link` and `.egg-info` metadata, and wheels will use `.dist-info` metadata. There should be only one metadata representation in the install space for a given package. The legacy setuptools build logic already has a special case for dealing with a switch from `.egg-info` to `.egg-link` and vice-versa. As we toss `.dist-info` into the mix, the need arises for a more robust solution. This new functionality is not currently used by colcon, but will be used as part of the transition to standards-based Python build support.
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
In order for colcon to consume wheels produced by PEP 517 build backends, we'll need to explicitly uninstall existing Python packages from the install space. This primarily stems from the differences in metadata representation, where the previous setuptools-only Python build mechanisms wrote
.egg-linkand.egg-infometadata, and wheels will use.dist-infometadata.There should be only one metadata representation in the install space for a given package. The legacy setuptools build logic already has a special case for dealing with a switch from
.egg-infoto.egg-linkand vice-versa. As we toss.dist-infointo the mix, the need arises for a more robust solution.This new functionality is not currently used by colcon, but will be used as part of the transition to standards-based Python build support.
Note
This looks like a lot of code. While it isn't a trivial change, all but one of the files are tests, and even that one file contains a significant amount of boilerplate for integrating with the
importlib.metadatamechanisms for distribution discovery.It's well-tested and thoroughly implemented because it will be a critical component of colcon's standards-based Python package building infrastructure.