Re: [Python-Dev] PEP 376 and PEP 302 - allowing import hooks to provide distribution metadata
At 03:13 PM 7/5/2009 +0200, Tarek Ziadé wrote:
The loader would still work with "DIST_NAME.egg-info" directories for compatibility with existing format in the query APIs, but the Distutils install command would rather create "DIST_NAME.metadata"
Note that this would then break setuptools without adding any benefit; ".metadata" is less precise and less unique than '.egg-info'. If you want a clearer name, '.pydist' or some such would at least be reasonably specific. (It'd still have a backward compatibility problem, but at least then there'd be some benefit to the name change.)
2009/7/5 P.J. Eby <pje@telecommunity.com>:
At 03:13 PM 7/5/2009 +0200, Tarek Ziadé wrote:
The loader would still work with "DIST_NAME.egg-info" directories for compatibility with existing format in the query APIs, but the Distutils install command would rather create "DIST_NAME.metadata"
Note that this would then break setuptools without adding any benefit; ".metadata" is less precise and less unique than '.egg-info'.
But if it's based on PEP 302 protocols and if the pkgutil code works with the sys.meta_path hook, setuptools could then provide its loader, based on its EggFormats and act as a provider without being broken. In that case, Distutils could provide a standard loader, with the change I mentioned.
If you want a clearer name, '.pydist' or some such would at least be reasonably specific. (It'd still have a backward compatibility problem, but at least then there'd be some benefit to the name change.)
I do find "DIST_NAME.metadata" well-named and specific. But I guess that's just bikeshedding :)
Tarek Ziadé wrote:
2009/7/5 P.J. Eby <pje@telecommunity.com>:
If you want a clearer name, '.pydist' or some such would at least be reasonably specific. (It'd still have a backward compatibility problem, but at least then there'd be some benefit to the name change.)
I do find "DIST_NAME.metadata" well-named and specific. But I guess that's just bikeshedding :)
pydist has the advantage of both being more intuitive than 'egginfo' while still making it clear that this is Python related metadata rather than, say, something added by an OS packaging utility. So no, I don't think it's bikeshedding: 'metadata': accurate but generic. Not clear that it relates to Python specifically (except that it happens to stored in a Python related directory) 'egginfo': accurate, specific and serves as a good mnemonic. However, use of the 'egg' jargon means that someone is unlikely to guess what it means without being told, and it's less obvious that this is Python related 'pydist': accurate, specific and without the disadvantages of the 'egg' jargon PJE points out that existing tools (setuptools, pip, etc) won't be compatible with the new format at all if it uses a new name, but I am having trouble seeing that as a *bad* thing. By using a new name for the directory we *guarantee* that old packaging utilities won't get confused by the new format (they simply won't acknowledge its existence). So +1 for pydist as the directory extension in PEP 376 (for the above reasons). Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia ---------------------------------------------------------------
Nick Coghlan <ncoghlan@gmail.com> writes:
'pydist': accurate, specific and without the disadvantages of the 'egg' jargon
PJE points out that existing tools (setuptools, pip, etc) won't be compatible with the new format at all if it uses a new name, but I am having trouble seeing that as a *bad* thing. By using a new name for the directory we *guarantee* that old packaging utilities won't get confused by the new format (they simply won't acknowledge its existence).
So +1 for pydist as the directory extension in PEP 376 (for the above reasons).
+1 for the same reasons. Thank you for expressing them. -- \ “We are not gonna be great; we are not gonna be amazing; we are | `\ gonna be *amazingly* amazing!” —Zaphod Beeblebrox, _The | _o__) Hitch-Hiker's Guide To The Galaxy_, Douglas Adams | Ben Finney
At 07:10 AM 7/6/2009 +1000, Nick Coghlan wrote:
By using a new name for the directory we *guarantee* that old packaging utilities won't get confused by the new format (they simply won't acknowledge its existence).
This is incorrect; they will get confused because they will think that the relevant package is *not* installed, and proceed to install a duplicate. That's why .egg-info was added to the stdlib in the first place.
But as I said earlier, if we use a PEP 302-like loader, distutils will be able to consume several loaders, so setuptools will be able to provide its storage strategy (naming and egg dir locations) So I don't understand why you are saying that it will be incompatible or get confused. 2009/7/6 P.J. Eby <pje@telecommunity.com>:
At 07:10 AM 7/6/2009 +1000, Nick Coghlan wrote:
By using a new name for the directory we *guarantee* that old packaging utilities won't get confused by the new format (they simply won't acknowledge its existence).
This is incorrect; they will get confused because they will think that the relevant package is *not* installed, and proceed to install a duplicate. That's why .egg-info was added to the stdlib in the first place.
-- Tarek Ziadé | http://ziade.org
I'm -1 on changing the name. For better or worse setuptools is the elephant in the room w.r.t. package management and it would IMHO be better to stay compatible (even if the stdlib only implements a subset of setuptools/pkg_resources) Ronald On 5 jul 2009, at 23:10, Nick Coghlan <ncoghlan@gmail.com> wrote:
Tarek Ziadé wrote:
2009/7/5 P.J. Eby <pje@telecommunity.com>:
If you want a clearer name, '.pydist' or some such would at least be reasonably specific. (It'd still have a backward compatibility problem, but at least then there'd be some benefit to the name change.)
I do find "DIST_NAME.metadata" well-named and specific. But I guess that's just bikeshedding :)
pydist has the advantage of both being more intuitive than 'egginfo' while still making it clear that this is Python related metadata rather than, say, something added by an OS packaging utility. So no, I don't think it's bikeshedding:
'metadata': accurate but generic. Not clear that it relates to Python specifically (except that it happens to stored in a Python related directory)
'egginfo': accurate, specific and serves as a good mnemonic. However, use of the 'egg' jargon means that someone is unlikely to guess what it means without being told, and it's less obvious that this is Python related
'pydist': accurate, specific and without the disadvantages of the 'egg' jargon
PJE points out that existing tools (setuptools, pip, etc) won't be compatible with the new format at all if it uses a new name, but I am having trouble seeing that as a *bad* thing. By using a new name for the directory we *guarantee* that old packaging utilities won't get confused by the new format (they simply won't acknowledge its existence).
So +1 for pydist as the directory extension in PEP 376 (for the above reasons).
Cheers, Nick.
-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia --------------------------------------------------------------- _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/ronaldoussoren%40mac.com
2009/7/6 Ronald Oussoren <ronaldoussoren@mac.com>:
I'm -1 on changing the name. For better or worse setuptools is the elephant in the room w.r.t. package management and it would IMHO be better to stay compatible (even if the stdlib only implements a subset of setuptools/pkg_resources)
I'd rather see the elephant evolves. I don't see why we should bend a standard we want to introduce in the stdlib, for a third-party package that is able to evolve to stick to a new standard without any problem.
2009/7/6 Tarek Ziadé <ziade.tarek@gmail.com>:
2009/7/6 Ronald Oussoren <ronaldoussoren@mac.com>:
I'm -1 on changing the name. For better or worse setuptools is the elephant in the room w.r.t. package management and it would IMHO be better to stay compatible (even if the stdlib only implements a subset of setuptools/pkg_resources)
I'd rather see the elephant evolves.
I don't see why we should bend a standard we want to introduce in the stdlib, for a third-party package that is able to evolve to stick to a new standard without any problem.
I agree with this. The big problem is that setuptools development seems to have essentially stagnated, and while that shouldn't be something we care about, it does need to be considered. Although my instinct is to fight against "do it our way because we won't change to do it your way" arguments, I have to ask whether the (purely internal) name of the metadata directory is really worth fighting over. I'm +0 on changing the name, as long as it's the *only* "do it this way because setuptools isn't going to change" issue. If more such issues come up, I'll become +1 on a clean break, to avoid endless such arguments and restrictions. Paul.
On 6 Jul, 2009, at 9:53, Tarek Ziadé wrote:
2009/7/6 Ronald Oussoren <ronaldoussoren@mac.com>:
I'm -1 on changing the name. For better or worse setuptools is the elephant in the room w.r.t. package management and it would IMHO be better to stay compatible (even if the stdlib only implements a subset of setuptools/pkg_resources)
I'd rather see the elephant evolves.
I don't see why we should bend a standard we want to introduce in the stdlib, for a third-party package that is able to evolve to stick to a new standard without any problem.
But why break existing code without having any other benifits? If I read the discussion correctly the name would be changed without any changes to the contents of the metadata directory. I would be more inclined to be in favour if the name change had a sound technical reason, such as a change of the contents of the directory which would make setuptools "egg-info" directories incompatible with the PEP376 ones. Ronald
2009/7/5 P.J. Eby <pje@telecommunity.com>:
At 03:13 PM 7/5/2009 +0200, Tarek Ziadé wrote:
The loader would still work with "DIST_NAME.egg-info" directories for compatibility with existing format in the query APIs, but the Distutils install command would rather create "DIST_NAME.metadata"
Note that this would then break setuptools without adding any benefit; ".metadata" is less precise and less unique than '.egg-info'. If you want a clearer name, '.pydist' or some such would at least be reasonably specific. (It'd still have a backward compatibility problem, but at least then there'd be some benefit to the name change.)
Personally, the filename doesn't bother me. It's the API name that I'd like changed (particularly as the contraction "egginfo" is clumsy in function names...) Paul.
participants (6)
-
Ben Finney -
Nick Coghlan -
P.J. Eby -
Paul Moore -
Ronald Oussoren -
Tarek Ziadé