On 22 January 2016 at 20:45, Donald Stufft <don...@stufft.io> wrote: > Hmm, in my head the three cases were more like: > > 1) The installed project is managed by a Python level tool which uses the > Python metadata as it’s database. Thus if you’re this kind of tool too, then > you can muck around here because things will be fine. > 2) The installed project is managed by something that isn’t a Python level > tool, and it has it’s own database and the .(egg|dist)-info files are not > understood by it. > 3) We don’t know what is managing the project. > > The first would be things like, pip, easy_install, and distil. These can all > easily interopt with each other because they’re all going to lay down > .egg-info or .dist-info files and read those same files. The second is things > like Conda, dpkg, yum, etc which are going to treat .egg-info or .dist-info > files as just another opaque file that is included in it’s package that it > has to lay down.
Good point - maybe that's how it *should* have been. My recollection of the discussions at the time was "put your tool name in here" and nobody really thought about the possibility of more than one tool co-operating. This was in the bad old days of "my tool is better than yours" flamewars :-( Switching to something like that model probably does need a PEP. But INSTALLER doesn't seem the right concept for that - it's more like wanting a file that defines how the project metadata is stored - "Metadata 2.0" or "OS" or "Conda" or whatever. Paul _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
