-
-
Notifications
You must be signed in to change notification settings - Fork 81
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Revisit relationship between Distribution and PathDistribution #445
Comments
I know I set this aside from the previous effort. I read it again today.
All of these methods rely primarily on
It is the intention that anyone anywhere can install a DistributionFinder on Prior to the 0.11 release (changes), there were two finders, one for folders on disk and another for wheels. That change consolidated those two finders into one by leveraging the abstractions in common between pathlib.Path and zipfile.Path. It's conceivable that no one is relying on the
Yes, that's a little awkward. Perhaps it would be better to be a top-level function or a classmethod on I recommend to take each of these concerns and articulate an issue and possibly propose an alternative approach, depending on how you're feeling about it with the above context. |
Yes, that is one solution. There is already
.locate_file()
which is not far off, except that its implementation inPathDistribution
precisely removes the metadata directory that we need in this case.More generally, I wonder if there is just a tad too much coupling between the
Distribution
andPathDistribution
classes?There is a mix of abstract and concrete methods in the
Distribution
base class, and several of the concrete methods seem fairly tightly bound to thePathDistribution
subclass. For example, theat()
static method creates and returns aPathDistribution
instance outright, and themetadata()
,entry_points()
,files()
, andrequires()
methods are all implemented with assumptions as to which files should be available and that the organization should resemble a dist-info or egg-info distribution.Now, there is (AFAICS) only the one (
PathDistribution
) subclass ofDistribution
available in this project, and I don't really have enough experience with this project or its users to really imagine what otherDistribution
subclasses would or could exist in the wild.Still, I would suspect that a subclass that was sufficiently different from
PathDistribution
to rather prefer subclassingDistribution
directly, would then find itself not merely implementing theread_text()
anlocate_file()
abstract methods, but would probably also need to _re_implement several ofmetadata()
,entry_points()
,files()
, orrequires()
as well.Hence, I would raise the question whether some of these methods would be better off with their concrete implementations moved into the
PathDistribution
subclass? (Of course leaving abstract methods behind inDistribution
where that makes sense.) This would grant these concrete methods direct access to the stuff they need insidePathDistribution
, instead of having to add more interfaces toDistribution
for stuff that really only makes sense forPathDistribution
.Still, this is a much bigger refactoring than I set out to do, and I would not feel comfortable starting this without consulting you.
Originally posted by @jherland in #437 (comment)
The text was updated successfully, but these errors were encountered: