[Python-Dev] [Catalog-sig] egg_info in PyPI (original) (raw)
Thomas Lotze thomas at thomas-lotze.de
Sat Sep 18 18:39:02 CEST 2010
- Previous message: [Python-Dev] [Catalog-sig] egg_info in PyPI
- Next message: [Python-Dev] [Catalog-sig] egg_info in PyPI
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Stephen J. Turnbull wrote:
In the meantime, it's better to let people using a competing "standard" (even if it's neither very good nor a "real" standard) do their thing until they see the light.
It's not even about the people who consume egg-info data seeing the light, it's about PEP-345 data actually being available. It's package authors who have to see the light, if you want to put it that way.
In the case of the dependency graphs, "good enough" is actually good enough as long as "100% correct" is not available. I am actually quite aware of the existence of PEP 345 and its advantages over legacy egg-info data and I wouldn't build an installer based on egg-info data straight from PyPI, but I feel it's good enough for my application that aims to visualise dependencies that people "know anyway". I have the following possibilities:
build graphs from PEP-345 info exclusively, which currently gives me a single graph with a single node (not useful now or for a long time),
find a volunteer who fills in PEP-345 information for all existing packages (not likely to happen),
give up and have a beer instead of building the application (not satisfying in the long run),
use PEP-345 information wherever possible and fall back to egg-info data otherwise, acknowledging and advertising the fact that the fall-back
data may not be 100% correct and having the package author specify PEP-345 information would be the way to go (good enough for my use case).
-- Thomas
- Previous message: [Python-Dev] [Catalog-sig] egg_info in PyPI
- Next message: [Python-Dev] [Catalog-sig] egg_info in PyPI
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]