@uranusjr, may I suggest the inclusion of setuptools-style entry points in the advantages?
I think this is an amazing feature/advantage of the Python packaging ecosystem.
Not so much in terms of console_scripts, but more in the fact that packages can advise themselves to others and how that allows the creation of a plugin ecosystem with almost no effort.
I agree it’s a very good feature, but do you have suggestions how I should include it? In the current format, each of the four topics is presented as having a “Python packaging made a bad design decision nobody else made” reputation, and expanded to discuss why those decisions aren’t actually bad, and in fact solve problems that would bite people if the design decision was made otherwise.
Entry points don’t fit in as well from I can tell right now, because nobody actually thinks entry points are bad, it’s just a feature Python packaging has while many others do not…? If it is also considered bad by some people and should be replaced by something else and I’m just not aware of it, please do raise examples so I can better present the topic.
I see… Well, while not intrinsically bad, there are some design decisions that could be considered controversial isn’t it?
For example, the fact that each package installed will have a .dist-info directory inside of it with a entry_points.txt file. Although not being a specialist here, I suspect that importlib.metadata also loops through all those files collecting the entry-points at runtime, instead of having living “service” or some kind of central indexing (e.g. a sqlite database file that could take advantage of whatever lookup optimizations sqlite uses).
This could be related to the Python package metadata stored directly beside the package installation, instead of living in a central location, couldn’t it?
I suspect that the most popular approach for discovery in other communities is by ‘globbing’ installation directories with pre-defined name prefixes, or with package managers allowing different packages to place files under shared folders (but again, I have limited knowledge about other ecosystem, so this might be just a wrong understanding).
Yes, storing metadata in distributed .dist-info directories is a special feature in Python packaging, and how entry points are now specified is heavily affected by it. I think it counts as a disadvantage and will add it as such. However, the specific format of entry point declaration does not really need to be constrained by .dist-info directories; there are possibilities we can explore to improve entry point lookup performance without changing this underlying design (the immediate thing that comes to mind is to store each entry point as a separate file and use filesystem tools to look them up, i.e. globbing).
Do you know any similar mechanisms to entry points? I can’t think of any clear direct equivalent from other ecosystems. There are some things that achieve similar goals (plug-in hooks), but no-one has a first-class feature that I know of.
I also have the same perception. It seems that all the other environments use “well-known” locations in the file system + package/file naming conventions for the dynamic discovery (or by explicitly passing paths to the application via env vars or CLI options).
You could tie this back to your talk structure by arguing that relying on “well-known” locations in the file system would not work very well with Python, given the fact that we use virtual environments most of the time (and therefore we can have multiple installations in the disk at the same time). Of course this argument is weak (as long as the language exposes a “prefix” for the “library environment” being currently used, it would be possible to achieve something similar), but Python makes it extremely easy.
An example of this approach of location/naming-based plugins can be found in these resources: