You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This does not change current behavior, but does a preliminary
refactoring on the way towards having multiple package-to-import
resolvers as discussed in #256 and associated issues.
Introduce a BasePackageResolver abstract base class to define the
interface for package resolvers, and provide, for now, two subclasses:
- LocalPackageResolver (renamed from LocalPackageLookup)
- IdentityMapping (refactored from resolve_dependencies())
Also refactor resolved_dependencies() to operate on a list of
BasePackageResolver objects: For each dependency name we go through the
list of resolvers until a resolver returns a Package object for this
name. We then add this Package to the returned mapping.
For now this list of resolvers is hardcoded to exactly two entries, the
LocalPackageResolver we were already using, and the IdentityMapping that
we were effectively falling back on for packages not found in the former.
Ideas for future work that build on this:
- Introduce more/different BasePackageResolver subclasses to do
different kinds of package resolving. E.g. user-defined mapping from a
config file. Resolving by looking up packages remotely on PyPI, etc.
- Make the list of resolvers user-configurable instead of hardcoded.
- Properly handle the case where none of the resolver find a package
mapping, i.e. _unmapped_ depenedencies.
0 commit comments