fix: Ensure that repository access is resilient against namespace packages #106
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.
We install MCs by registering the MC repo's
__path__
attribute as an entry point. That__path__
attribute is a sequence, and FIREWHEEL currently grabs the first item in that sequence to be the repository path.However, it appears that when an MC package repo does not have a top-level
__init__.py
(e.g.,firewheel_repo_dns
) and it is installed in editable mode, that package is treated as a namespace package. In this case, the path that we would like to register via the entry point is not necessarily the first item in the sequence (it looks like the first entry is the empty placeholder directory in thesite-packages
location, and the second entry is / may be the path to the actual modules).I've put a bit of thought into how to resolve this problem, and my thinking is that there might not be a downside to including every item in the
__path__
sequence. For one thing, this way we don't have to make any assumptions about where in our sequence the path we really want will be. It could be first, second, last, wherever. Path elements of__path__
that do not have MC modules are ignored as repositories by themc list
helper. And, in the case that someone actually does make an MC repo a real namespace package (e.g., a package where the components are not actually in the same repo, I think), we will still include all of the elements.An alternative is that we just include an
__init__.py
at the top-level all of our MC package repos, but the missing one infirewheel_repo_dns
suggests that this might be a route that persistently gives rise to tricky bugs if that empty, often-not-required, seemingly useless file is missing. We'd need to make sure that gets documented really well.