Repository navigation
Revisit relationship between Distribution and PathDistribution #445
Description
Activity
I know I set this aside from the previous effort. I read it again today.
a subclass that was sufficiently different from
PathDistributionwould probably also need to _re_implement several ofmetadata(),entry_points(),files(), orrequires().All of these methods rely primarily on
read_text, so I'd expect them to work without re-implementation. At least, that's the design - if the Distribution subclass implements aread_text, which given a filename returns the text of that metadata "file", the other methods rely on that interface to process the contents. The fact that some of these (filesin particular) are highly aligned to the implementation details of egg-info and distinfo is an artifact, but there for practicality. I'd like to deprecate the egg-based solution, but only after suitable replacements are in place (e.g. Setuptools no longer generates them under any circumstances).I don't really have enough experience with this project or its users to really imagine what other
Distributionsubclasses would or could exist in the wild.It is the intention that anyone anywhere can install a DistributionFinder on
sys.meta_path. You could, for example, build a database of Python packages and have them importable with metadata, or even build an importer system that imports directly from PyPI and loads the metadata from artifacts in PyPI without downloading them to disk. We explicitly tried not to couple too tightly to the existing implementation of Folders-on-Disk and Zipfiles on sys.path.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
Distributionsubclass at this point, but it still seems like a meaningful abstraction to maintain - to avoid embedding reliance on the "pathlib-like" interface or for paths to exist on a file system.the
at()static method creates and returns aPathDistributioninstanceYes, that's a little awkward. Perhaps it would be better to be a top-level function or a classmethod on
PathDistributionor something else.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 inPathDistributionprecisely 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
DistributionandPathDistributionclasses?There is a mix of abstract and concrete methods in the
Distributionbase class, and several of the concrete methods seem fairly tightly bound to thePathDistributionsubclass. For example, theat()static method creates and returns aPathDistributioninstance 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 ofDistributionavailable in this project, and I don't really have enough experience with this project or its users to really imagine what otherDistributionsubclasses would or could exist in the wild.Still, I would suspect that a subclass that was sufficiently different from
PathDistributionto rather prefer subclassingDistributiondirectly, 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
PathDistributionsubclass? (Of course leaving abstract methods behind inDistributionwhere that makes sense.) This would grant these concrete methods direct access to the stuff they need insidePathDistribution, instead of having to add more interfaces toDistributionfor 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)