Re: [Python-Dev] PEP 376 and PEP 302 - allowing import hooks to provide distribution metadata
At 08:43 PM 7/5/2009 +0200, Tarek Ziadé wrote:
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.
You misunderstand me. The whole point of putting .egg-info in distutils in the first place was to enable setuptools to detect the presence of disutils-installed packages. That's what's broken by changing the name.
2009/7/6 P.J. Eby <pje@telecommunity.com>:
At 08:43 PM 7/5/2009 +0200, Tarek Ziadé wrote:
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.
You misunderstand me. The whole point of putting .egg-info in distutils in the first place was to enable setuptools to detect the presence of disutils-installed packages. That's what's broken by changing the name.
This implies that there is no possibility that setuptools will be changed to support the new standard. That's patently false. Whether you *want* to change setuptools in such a way is up to you. And it's worth a note in the PEP if this change is made, that it will require a change to setuptools if that package is still to recognise distutils-installed packages. Paul.
2009/7/6 Paul Moore <p.f.moore@gmail.com>:
2009/7/6 P.J. Eby <pje@telecommunity.com>:
At 08:43 PM 7/5/2009 +0200, Tarek Ziadé wrote:
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.
You misunderstand me. The whole point of putting .egg-info in distutils in the first place was to enable setuptools to detect the presence of disutils-installed packages. That's what's broken by changing the name.
Forget about my previous mail, I didn't see that answer,
This implies that there is no possibility that setuptools will be changed to support the new standard. That's patently false. Whether you *want* to change setuptools in such a way is up to you. And it's worth a note in the PEP if this change is made, that it will require a change to setuptools if that package is still to recognise distutils-installed packages.
+1 setuptools is built on the top of distutils, not the contrary. And if setuptools wants to query installed distribution, it will have to be changed to use the query functions added in pkgutil. Tarek
P.J. Eby wrote:
At 08:43 PM 7/5/2009 +0200, Tarek Ziadé wrote:
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.
You misunderstand me. The whole point of putting .egg-info in distutils in the first place was to enable setuptools to detect the presence of disutils-installed packages. That's what's broken by changing the name.
How much information does setuptools actually need in order to tell that a distribution is already present? Presumably the existing .egginfo files generated by distutils are sufficient for that task? If so, I'd still prefer to keep the new metadata safely out of reach of the legacy package management systems that don't understand it, while having distutils retain the ability to generate a legacy ".egginfo" file to warn off the existing package management tools from installing the same distribution again. So instead of ".egginfo becomes a directory" as in the current version of PEP 376, the existing distutils .egginfo file generation would instead remain unchanged with a ".pydist" directory being added alongside to hold all the new goodies. That way, the legacy formats (EGG-INFO, .egg-info file, .egg-info directory) continue to play as well together as they do now, while the new distutils system will understand .pydist directories natively and allow the injection of hook implementations by the third party package management tools in order to understand the old formats. That seems like it will give us the best of both worlds - a clean base to work from in the future, but without breaking the existing interoperability mechanisms (at least in the short term - maybe by the time 3.3 rolls around we will be able to start thinking about deprecating the legacy .egginfo formats, but even considering that question is a long way off). Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia ---------------------------------------------------------------
2009/7/6 Nick Coghlan <ncoghlan@gmail.com>:
P.J. Eby wrote:
At 08:43 PM 7/5/2009 +0200, Tarek Ziadé wrote:
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.
You misunderstand me. The whole point of putting .egg-info in distutils in the first place was to enable setuptools to detect the presence of disutils-installed packages. That's what's broken by changing the name.
This is getting confusing. Is Phillip saying that setuptools will cope with the file changing to a directory without modification, but it can't handle a change in the name? My site-packages has a confusing mix of egginfo directories and files. Note that I NEVER use setuptools other than where an existing package's setup.py requires it. In that case, I still only do python setup.py bdist_wininst and install the generated installer. So is PEP 376 going to be able to cope with the stuff I have installed at the moment? If not, what's the point??? Example: I have the "coverage" package installed. It does not use setuptools at runtime - I could happily install it from a bdist_wininst on a machine without setuptools installed, and it would run fine. (In fact, that's what I did!) It has created a coverage-3.0-py2.6.egg-info *directory* in my site-packages, with no RECORD file - presumably, this is in a setuptools format. If setuptools is not going to change to conform to PEP 376, then any tools built using PEP 376 will fail to recognise my coverage install. Which, as far as I am concerned, is a completely standard bdist_wininst installer. In fact, the above strongly suggests to me that PEP 376 must NOT follow setuptools conventions - otherwise, it will end up clashing with the files setuptools is putting on my system.
How much information does setuptools actually need in order to tell that a distribution is already present? Presumably the existing .egginfo files generated by distutils are sufficient for that task?
It appears so, but setuptools doesn't use (or create!!!) those files in its own installer formats.
If so, I'd still prefer to keep the new metadata safely out of reach of the legacy package management systems that don't understand it, while having distutils retain the ability to generate a legacy ".egginfo" file to warn off the existing package management tools from installing the same distribution again.
So for a minimal case of a single .py file packaged up as a distribution, we now have the .py file, a legacy .egginfo file, a new .pydist directory containing RECORD and PKG-INFO files? That's getting silly.
So instead of ".egginfo becomes a directory" as in the current version of PEP 376, the existing distutils .egginfo file generation would instead remain unchanged with a ".pydist" directory being added alongside to hold all the new goodies. That way, the legacy formats (EGG-INFO, .egg-info file, .egg-info directory) continue to play as well together as they do now, while the new distutils system will understand .pydist directories natively and allow the injection of hook implementations by the third party package management tools in order to understand the old formats.
That seems like it will give us the best of both worlds - a clean base to work from in the future, but without breaking the existing interoperability mechanisms (at least in the short term - maybe by the time 3.3 rolls around we will be able to start thinking about deprecating the legacy .egginfo formats, but even considering that question is a long way off).
And yet, given that PEP 376 is explicitly being designed with a goal being to act as the common standard that *all* package management formats can use, is it not the whole point that once it's defined and we have achieved consensus, existing package managers will switch to using it rather than retaining a range of custom formats? I honestly fail to see why we are catering to this "setuptools cannot change" view. Usually, it's the standard library that cannot change, because of the longer release cycle of the core. If a standard is agreed, and setuptools won't conform to it, maybe it's time for someone to fork setuptools (unilaterally, if Phillip can't agree to an amicable transfer). Otherwise setuptools will remain a roadblock for any development of distutils. Frustrated-ly y'rs Paul.
On Mon, Jul 6, 2009 at 5:14 PM, Paul Moore<p.f.moore@gmail.com> wrote:
[...] And yet, given that PEP 376 is explicitly being designed with a goal being to act as the common standard that *all* package management formats can use, is it not the whole point that once it's defined and we have achieved consensus, existing package managers will switch to using it rather than retaining a range of custom formats?
That's the goal from the very beginning.
I honestly fail to see why we are catering to this "setuptools cannot change" view. Usually, it's the standard library that cannot change, because of the longer release cycle of the core. If a standard is agreed, and setuptools won't conform to it, maybe it's time for someone to fork setuptools (unilaterally, if Phillip can't agree to an amicable transfer). Otherwise setuptools will remain a roadblock for any development of distutils.
Frustrated-ly y'rs
+1 why can't we just go ahead and continue the work as we started with PEP 376, introducing your work on PEP 302-like behavior. Then if we get a consensus on this PEP and introduce it in 2.7/3.2, setuptools will have to follow this consensus. FWIW I am also frustrated because the setuptools development has been stopped 9 months ago, and *doesn't work anymore with the current distutils trunk*. There are a lot of patches waiting in the setuptools tracker people wrote. I hate to say this but this project needs an active maintainer or it's going to die. So I've said in distutils-sig that I would start my own branch of setuptools before 2.7/3.2 is out for the people in the community that relies on this package. Not to maintain the project because I have a lot to do already on distutils side. But at least to make sure everyone can work with the upcoming releases of Python 2.x and 3.X without having their setup.py broken (and switch eventually to a plain distutils solution maybe) Tarek
2009/7/6 Tarek Ziadé <ziade.tarek@gmail.com>:
why can't we just go ahead and continue the work as we started with PEP 376, introducing your work on PEP 302-like behavior.
Then if we get a consensus on this PEP and introduce it in 2.7/3.2, setuptools will have to follow this consensus.
Essentially, because when I ask questions, responses along the lines of "you have to do it like X because setuptools does that" come back, and (not being a setuptools user) I can't tell whether there's a valid reason in there. I'm uncomfortable assuming that setuptools experience is irrelevant, but I can't distinguish between valid arguments and "setuptools can't change" arguments. I need to write another email with a list of outstanding open issues. If we can thrash them out *without* getting bogged down in setuptools compatibility questions, then I think we can move forward again. I'll do that this evening. Paul.
On Mon, Jul 6, 2009 at 5:53 PM, Paul Moore<p.f.moore@gmail.com> wrote:
2009/7/6 Tarek Ziadé <ziade.tarek@gmail.com>:
why can't we just go ahead and continue the work as we started with PEP 376, introducing your work on PEP 302-like behavior.
Then if we get a consensus on this PEP and introduce it in 2.7/3.2, setuptools will have to follow this consensus.
Essentially, because when I ask questions, responses along the lines of "you have to do it like X because setuptools does that" come back, and (not being a setuptools user) I can't tell whether there's a valid reason in there.
Notice that we created PEP 376 in distutils-SIG with most of the valid reasons/use cases setuptools had, with the help of Phillip, before I brought it up again on python-dev.
I'm uncomfortable assuming that setuptools experience is irrelevant, but I can't distinguish between valid arguments and "setuptools can't change" arguments.
I need to write another email with a list of outstanding open issues. If we can thrash them out *without* getting bogged down in setuptools compatibility questions, then I think we can move forward again. I'll do that this evening.
Ok, I'll wait for your work to work on the PEP again then, and your push in the hg repo as well.
Paul Moore <p.f.moore@gmail.com> writes:
In fact, the above strongly suggests to me that PEP 376 must NOT follow setuptools conventions - otherwise, it will end up clashing with the files setuptools is putting on my system.
I think the argument for a separate ‘.pydist’ metadata directory, normative in PEP 376, is a good one.
If so, I'd still prefer to keep the new metadata safely out of reach of the legacy package management systems that don't understand it, while having distutils retain the ability to generate a legacy ".egginfo" file to warn off the existing package management tools from installing the same distribution again.
So for a minimal case of a single .py file packaged up as a distribution, we now have the .py file, a legacy .egginfo file, a new .pydist directory containing RECORD and PKG-INFO files?
That's getting silly.
The burden of switching is that we need a compatibility bridge. If that means that a tool must support the old while also supporting the new, that's not silliness in the tool, but acknowledgement of the silliness we're migrating away from. That doesn't mean, though, that PEP 376 needs to mention the old format at all; just that distutils should support it, deprecated, until a time when it's deemed safe to remove. In fact, I think it's best that PEP 376 discuss *only* the format we're trying to migrate to, and support for existing formats is firmly outside its scope.
And yet, given that PEP 376 is explicitly being designed with a goal being to act as the common standard that *all* package management formats can use, is it not the whole point that once it's defined and we have achieved consensus, existing package managers will switch to using it rather than retaining a range of custom formats?
Again, that needs to be a gradual process. Supporting a new format as defined in PEP 376 needs not (indeed, I would argue *should* not) mean the tool drop support for old formats immediately. There needs to be a compatibility chain to allow for fast migration *and* slow migration, since there will be a broad mix of both. Let PEP 376 discuss a format that is clean and new, but let discussions leading to that format acknowledge that it must allow (*not* require) parallel support of old formats for some time. -- \ “I love to go down to the schoolyard and watch all the little | `\ children jump up and down and run around yelling and screaming. | _o__) They don't know I'm only using blanks.” —Emo Philips | Ben Finney
2009/7/7 Ben Finney <ben+python@benfinney.id.au>:
Paul Moore <p.f.moore@gmail.com> writes:
In fact, the above strongly suggests to me that PEP 376 must NOT follow setuptools conventions - otherwise, it will end up clashing with the files setuptools is putting on my system.
I think the argument for a separate ‘.pydist’ metadata directory, normative in PEP 376, is a good one.
I've been convinced otherwise. There's no long-term benefit (the directory layout and format is the same, so it's a purely cosmetic change) and we're doing no favours to anyone just adding a new format for the sake of it. Paul.
Paul Moore wrote:
2009/7/7 Ben Finney <ben+python@benfinney.id.au>:
Paul Moore <p.f.moore@gmail.com> writes:
In fact, the above strongly suggests to me that PEP 376 must NOT follow setuptools conventions - otherwise, it will end up clashing with the files setuptools is putting on my system. I think the argument for a separate ‘.pydist’ metadata directory, normative in PEP 376, is a good one.
I've been convinced otherwise. There's no long-term benefit (the directory layout and format is the same, so it's a purely cosmetic change) and we're doing no favours to anyone just adding a new format for the sake of it.
The PEP should take the chance to define not only the directory, but also the complete set of files in there and their format. A typical setuptools dir looks like this: dependency_links.txt namespace_packages.txt not-zip-safe PKG-INFO requires.txt SOURCES.txt top_level.txt Ie. a complete mess of upper-case/lower-case names, names with underscores or hyphens as word separator, files with extensions, files without them. This needs some serious cleanup. A new dir name will allow to do this, so +1 on a new dir name. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jul 07 2009)
Python/Zope Consulting and Support ... http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/
2009/7/7 M.-A. Lemburg <mal@egenix.com>:
The PEP should take the chance to define not only the directory, but also the complete set of files in there and their format.
A typical setuptools dir looks like this:
dependency_links.txt namespace_packages.txt not-zip-safe PKG-INFO requires.txt SOURCES.txt top_level.txt
Ie. a complete mess of upper-case/lower-case names, names with underscores or hyphens as word separator, files with extensions, files without them.
This needs some serious cleanup.
A new dir name will allow to do this, so +1 on a new dir name.
I agree the current situation is a mess. I believe that everything you mention is related to setuptools - so essentially, we have the situation: - the existing setuptools format is a mess (at least in the opinion of MAL and me :-)) - PEP 376 is an opportunity to consider cleanup - there are some strong supporters of keeping things setuptools-compatible - nobody has come forward with any other real-world use case than setuptools - consequently, those of us arguing for cleanup are talking theoretically :-( - Do you (MAL) have any real use for this data? Any non-setuptools use case, no matter how small, would really help here. I suspect practicality will beat purity here. Which would be fine, if the "practical" cases weren't just setuptools. I understood that there was a lot of interest in a "distutils cleanup" from the packaging community. And yet so far in this discussion, the main participants have seemed to be (apologies to anyone if I've misunderstood their position): - Tarek, trying to get the proposal he thrashed out in the distutils SIG agreed - Me, advocating Windows issues and PEP 302 integration (to cover eggs and general flexibility) - Phillip (and occasional others), representing setuptools POV - Interested python-dev participants Nobody representing any other 3rd party packaging solution than setuptools. Much as I'd like to, I can't really argue the case for breaking setuptools compatibility without practical reasons. And if we're not going to do that, PEP 376 reduces to a further stage of the incremental move of setuptools into distutils core (by removing the partial solution of a .egg-info file, and replacing it with a full setuptools .egg-info directory, plus a few introspection APIs as a sweetener). 2009/7/7 Ronald Oussoren <ronaldoussoren@mac.com>:
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.
See MAL's comments above, and my response. If (and only if!) his proposal is accepted, then a name change starts to be worth discussing further. As things stand at the moment, the structure appears to be setuptools-compatibile (other than the new RECORD file, which Phillip has committed to adding) so a name change isn't worth it. I can't comment myself on setuptools compatibility, so I'm assuming here that Phillip will speak up if the proposed format is *not* compatible... Paul.
Paul Moore wrote:
2009/7/7 M.-A. Lemburg <mal@egenix.com>:
The PEP should take the chance to define not only the directory, but also the complete set of files in there and their format.
A typical setuptools dir looks like this:
dependency_links.txt namespace_packages.txt not-zip-safe PKG-INFO requires.txt SOURCES.txt top_level.txt
Ie. a complete mess of upper-case/lower-case names, names with underscores or hyphens as word separator, files with extensions, files without them.
This needs some serious cleanup.
A new dir name will allow to do this, so +1 on a new dir name.
I agree the current situation is a mess. I believe that everything you mention is related to setuptools - so essentially, we have the situation:
- the existing setuptools format is a mess (at least in the opinion of MAL and me :-)) - PEP 376 is an opportunity to consider cleanup - there are some strong supporters of keeping things setuptools-compatible - nobody has come forward with any other real-world use case than setuptools - consequently, those of us arguing for cleanup are talking theoretically :-( - Do you (MAL) have any real use for this data? Any non-setuptools use case, no matter how small, would really help here.
No, we currently don't have a package installer that would implement what setuptools does on the user side, but without all the black magic stuff. What we do have is a somewhat different approach to packaging binary packages: we call them pre-built archives. The idea is that the developer runs a complete build command on the target platform, the bdist_prebuilt command then packages up everything (including the current state of distutils) and the user then runs the usual python setup.py install on her machine to complete the setup. The major advantage here is that the user actually has full control over where things are installed and how. So whatever distutils implements as part of the install command, this format will also support. We also provide an uninstall command, that basically runs an installation in reverse. Something else we've done recently is write a bdist_egg command that creates .egg files without relying on setuptools. It's fairly easy to do and if there's interest, I can add that to core distutils. Changing the layout of the EGG-INFO dir embedded in those .egg files is pretty easy to do, so I don't really see much of a problem with changing it or renaming the dir.
I suspect practicality will beat purity here. Which would be fine, if the "practical" cases weren't just setuptools.
I understood that there was a lot of interest in a "distutils cleanup" from the packaging community. And yet so far in this discussion, the main participants have seemed to be (apologies to anyone if I've misunderstood their position):
- Tarek, trying to get the proposal he thrashed out in the distutils SIG agreed - Me, advocating Windows issues and PEP 302 integration (to cover eggs and general flexibility) - Phillip (and occasional others), representing setuptools POV - Interested python-dev participants
Nobody representing any other 3rd party packaging solution than setuptools.
Well I've added another one above, the pre-built approach :-) Writing an uninstall command really isn't all that hard, provided you stick with the standard distutils "python setup.py install" dance. The whole packaging approach only complicates things, IMHO.
Much as I'd like to, I can't really argue the case for breaking setuptools compatibility without practical reasons. And if we're not going to do that, PEP 376 reduces to a further stage of the incremental move of setuptools into distutils core (by removing the partial solution of a .egg-info file, and replacing it with a full setuptools .egg-info directory, plus a few introspection APIs as a sweetener).
Uhm, we are talking about a Python standard here and since there is no prior implementation in Python stdlib, we're not breaking anything and are free to design whatever we like. Of course, it does make a lot of sense to build upon things that have been used in the past, so looking at setuptools is certainly a useful strategy. However, let's learn from their mistakes and take the change to clean up things a bit. There are good reasons to do so: * the naming scheme should be concise * the meta-data directory should get a name that doesn't imply any specific distribution form... Calling the directory .egg-info is natural if you're only dealing with eggs. It is not when running standard "python setup.py install" or having a mixed setup using different packaging mechanisms.
2009/7/7 Ronald Oussoren <ronaldoussoren@mac.com>:
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.
See MAL's comments above, and my response. If (and only if!) his proposal is accepted, then a name change starts to be worth discussing further. As things stand at the moment, the structure appears to be setuptools-compatibile (other than the new RECORD file, which Phillip has committed to adding) so a name change isn't worth it.
I can't comment myself on setuptools compatibility, so I'm assuming here that Phillip will speak up if the proposed format is *not* compatible...
-- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jul 07 2009)
Python/Zope Consulting and Support ... http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/
On Tue, Jul 7, 2009 at 11:28 AM, M.-A. Lemburg<mal@egenix.com> wrote:
Writing an uninstall command really isn't all that hard, provided you stick with the standard distutils "python setup.py install" dance. The whole packaging approach only complicates things, IMHO.
You can't expect people to keep the distribution they used to install in a corner of their hard drive, to make sure they will be able to uninstall it (or to ask them to download it again) That's all about the RECORD files and the asymetric uninstall script described in PEP 376. having an uninstall command on the top of the uninstall script is a nice shortcut though.
2009/7/7 M.-A. Lemburg <mal@egenix.com>:
Well I've added another one above, the pre-built approach :-)
Thanks! That's a lot of help. Are there any public examples, or is your format only used internally? Would you expect to use any of the new pkgutil APIs - for example, to check if a distribution is installed, and/or the installed version? Or to check you're not overwriting a file owned by another distribution? Or would you get any value from storing your own format-specific metadata files in the egg-info directory? If all you care about is that setup.py install continues to work, my suspicion is that PEP 376 won't have much to offer you, whatever happens. Paul.
Paul Moore <p.f.moore@gmail.com> writes:
I agree the current situation is a mess. I believe that everything you mention is related to setuptools - so essentially, we have the situation:
- the existing setuptools format is a mess (at least in the opinion of MAL and me :-))
No argument from me on this point.
- PEP 376 is an opportunity to consider cleanup - there are some strong supporters of keeping things setuptools-compatible
Your implication seems to be that these two are incompatible. It should be noted that it's possible to clean up, by having a separate (e.g. ‘.pydist’) directory as the new standard, with “cleaned up” standard content, and continue backward compatibility in the actual tools while deprecating the old ‘.egg-info’ format for some time until finally removing that support.
Much as I'd like to, I can't really argue the case for breaking setuptools compatibility without practical reasons.
Agreed. I think we should be making it clear that ‘.egg-info’ is not going to evolve any further, and that it will eventually go away; but not remove support for it until there's a clearly established replacement. -- \ “I got up the other day, and everything in my apartment has | `\ been stolen and replaced with an exact replica.” —Steven Wright | _o__) | Ben Finney
2009/7/7 Ben Finney <ben+python@benfinney.id.au>:
- PEP 376 is an opportunity to consider cleanup - there are some strong supporters of keeping things setuptools-compatible
Your implication seems to be that these two are incompatible. It should be noted that it's possible to clean up, by having a separate (e.g. ‘.pydist’) directory as the new standard, with “cleaned up” standard content, and continue backward compatibility in the actual tools while deprecating the old ‘.egg-info’ format for some time until finally removing that support.
Phillip argued strongly against this. I'm not going to repeat his arguments - they seemed to make sense to me at the time, but I haven't internalised them well enough that I'd be willing to try to repeat them here. The crux of all this seems to be setuptools' backwards compatibility issues, As someone who has a very strong dislike of setuptools (the implementation, not the ideas), I'm trying very, very hard to leave it to someone else to say "stuff setuptools, this is a core distutils proposal, setuptools can keep up or die" :-) Paul.
Paul Moore wrote:
2009/7/7 Ben Finney <ben+python@benfinney.id.au>:
- PEP 376 is an opportunity to consider cleanup - there are some strong supporters of keeping things setuptools-compatible Your implication seems to be that these two are incompatible. It should be noted that it's possible to clean up, by having a separate (e.g. ‘.pydist’) directory as the new standard, with “cleaned up” standard content, and continue backward compatibility in the actual tools while deprecating the old ‘.egg-info’ format for some time until finally removing that support.
Phillip argued strongly against this. I'm not going to repeat his arguments - they seemed to make sense to me at the time, but I haven't internalised them well enough that I'd be willing to try to repeat them here.
The crux of all this seems to be setuptools' backwards compatibility issues, As someone who has a very strong dislike of setuptools (the implementation, not the ideas), I'm trying very, very hard to leave it to someone else to say "stuff setuptools, this is a core distutils proposal, setuptools can keep up or die" :-)
Actually, the approach Ben suggests is the same as the one I suggested for dealing with the backwards compatibility problem (i.e. distutils would install both the existing .egg-info for detection by existing packaging tools, while putting the new stuff in a .pydist directory). The argument against *that* approach to backwards compatibility is the accumulation of cruft in site-packages (and other module installation directories) since even a simple installation of a single module or small package would now be generating at least *three* entries in the relevant directory (.egg-info, .pydist and the module or package itself). Retaining the .egg-info naming provides detection of installed distributions by old packaging systems with a minimum of cruft on the end user's system. The only possible advantage changing the extension name might give us is making it fractionally easier to clean up the contents of the .egg-info directory, but I don't think it will actually make that much difference (i.e. it really shouldn't be that hard to keep the new PEP 376 based filenames all UPPERCASE and distinct from any filenames currently stored in the directory by setuptools or other packaging utilities) Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia ---------------------------------------------------------------
participants (6)
-
Ben Finney -
M.-A. Lemburg -
Nick Coghlan -
P.J. Eby -
Paul Moore -
Tarek Ziadé