fix: use package name from metadata file as package name #4
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.
When evaluating local package names in PyPackage.install(), a package's "canonical_name" should reference the package name from the metadata file, not the parent directory of the package.
Motivation
I tried linking a library to another library using namespace packages (eg
acme.lib-a
). The existinginstall()
function compared thepkg.canonical_name
with the name listed in the dependencies. Thepkg.canonical_name
was returning the parent directory of the package, relying on the package parent directory to have the same name as the python package. This is not always going to be the same as the package name, as some developers have different parent directory names than their project name. I added a property to the metadata classes to provide the package name as reported by the metadata file. I called this propertypackage_name
, asname
was already a property for the class. I considered renaming the existingname
property to something else, liketype
, but didn't want to create too many changes. It's a bit confusing that the Metadata classes contain properties that describe the metadata file itself (eg "name" and "filename") and properties that describe the python package (like "version")I also updated a test case that was creating demo packages that all had the name "foo". This caused the tests to "add" a dependency fail, because adding "foo" to any project would cause a circular dependency (since all demo projects were named "foo" in their metadata file.)
This highlights that guardrails should probably be added that prevent self dependencies, or circular dependencies.