-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I haven't heard back from Richard Jones, who is the PEP owner, but have perpared to update PEP 345[1] in line with what to be the majority view (at PyCon) for adding "distribution-level" dependency metadata (as opposed to importable package / module dependencies) to the PKG-INFO file. I have backed off on the notion of overloading 'Requires:' / 'Provides:' / 'Obsoletes:', following Jim's notion of deprecating them in favor of new fields. I named them 'Requires-Dist:', 'Provides-Dist:', and 'Obsoletes-Dist'. "Stock" distutils should probably spell the arguments to distutils.core.setup predictably: 'requires_dist', 'provides_dist', 'obsoletes_dist'. setuptools can treat 'install_requires' as an undeprecated alias for 'requires_dist'. [1] http://svn.python.org/view/peps/trunk/pep-0345.txt?view=markup Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJ3iiI+gerLs4ltQ4RAtVLAKCZsXVoS9a0f0B0o8eAErsPmZP6OACePvJ7 8nx3i8Z4LEOsj0SsNczDtAk= =l7Kk -----END PGP SIGNATURE-----
Jim started a branch during Pycon, maybe you can push your work over there for review here ? Also, I am wondering if we shouldn't merge it with PEP 376, where we might want to add a REQUIRES file into the egg.info structure, besides the PKG-INFO file. Cheers Tarek On Thu, Apr 9, 2009 at 6:55 PM, Tres Seaver <tseaver@palladion.com> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I haven't heard back from Richard Jones, who is the PEP owner, but have perpared to update PEP 345[1] in line with what to be the majority view (at PyCon) for adding "distribution-level" dependency metadata (as opposed to importable package / module dependencies) to the PKG-INFO file.
I have backed off on the notion of overloading 'Requires:' / 'Provides:' / 'Obsoletes:', following Jim's notion of deprecating them in favor of new fields. I named them 'Requires-Dist:', 'Provides-Dist:', and 'Obsoletes-Dist'.
"Stock" distutils should probably spell the arguments to distutils.core.setup predictably: 'requires_dist', 'provides_dist', 'obsoletes_dist'. setuptools can treat 'install_requires' as an undeprecated alias for 'requires_dist'.
[1] http://svn.python.org/view/peps/trunk/pep-0345.txt?view=markup
Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFJ3iiI+gerLs4ltQ4RAtVLAKCZsXVoS9a0f0B0o8eAErsPmZP6OACePvJ7 8nx3i8Z4LEOsj0SsNczDtAk= =l7Kk -----END PGP SIGNATURE-----
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
-- Tarek Ziadé | Association AfPy | www.afpy.org Blog FR | http://programmation-python.org Blog EN | http://tarekziade.wordpress.com/
Btw we also need to add some metadata that should be described in PEP 345 and added in PKG-INFO: - maintainer and maintainer_email see: http://bugs.python.org/issue3686 On Thu, Apr 9, 2009 at 7:05 PM, Tarek Ziadé <ziade.tarek@gmail.com> wrote:
Jim started a branch during Pycon, maybe you can push your work over there for review here ?
Also, I am wondering if we shouldn't merge it with PEP 376, where we might want to add a REQUIRES file into the egg.info structure, besides the PKG-INFO file.
Cheers Tarek
On Thu, Apr 9, 2009 at 6:55 PM, Tres Seaver <tseaver@palladion.com> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I haven't heard back from Richard Jones, who is the PEP owner, but have perpared to update PEP 345[1] in line with what to be the majority view (at PyCon) for adding "distribution-level" dependency metadata (as opposed to importable package / module dependencies) to the PKG-INFO file.
I have backed off on the notion of overloading 'Requires:' / 'Provides:' / 'Obsoletes:', following Jim's notion of deprecating them in favor of new fields. I named them 'Requires-Dist:', 'Provides-Dist:', and 'Obsoletes-Dist'.
"Stock" distutils should probably spell the arguments to distutils.core.setup predictably: 'requires_dist', 'provides_dist', 'obsoletes_dist'. setuptools can treat 'install_requires' as an undeprecated alias for 'requires_dist'.
[1] http://svn.python.org/view/peps/trunk/pep-0345.txt?view=markup
Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFJ3iiI+gerLs4ltQ4RAtVLAKCZsXVoS9a0f0B0o8eAErsPmZP6OACePvJ7 8nx3i8Z4LEOsj0SsNczDtAk= =l7Kk -----END PGP SIGNATURE-----
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
-- Tarek Ziadé | Association AfPy | www.afpy.org Blog FR | http://programmation-python.org Blog EN | http://tarekziade.wordpress.com/
-- Tarek Ziadé | Association AfPy | www.afpy.org Blog FR | http://programmation-python.org Blog EN | http://tarekziade.wordpress.com/
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tarek Ziadé wrote:
Btw we also need to add some metadata that should be described in PEP 345 and added in PKG-INFO:
- maintainer and maintainer_email
Revised patch attached. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJ3juY+gerLs4ltQ4RAnRQAKCiUkNgR7wNDol8xQKEKYVWRvQsxgCgyrrI OWhYOK7TGE4NyWpn0d+/0Rg= =nhuG -----END PGP SIGNATURE-----
On Thu, Apr 9, 2009 at 8:16 PM, Tres Seaver <tseaver@palladion.com> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Tarek Ziadé wrote:
Btw we also need to add some metadata that should be described in PEP 345 and added in PKG-INFO:
- maintainer and maintainer_email
Revised patch attached.
Added : http://svn.python.org/projects/peps/branches/jim-update-345/pep-0345.txt I'll update the wiki accordingly, and update it everytime we need it.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tarek Ziadé wrote:
Jim started a branch during Pycon, maybe you can push your work over there for review here ?
AFAICT, Jim hasn't checked anything into that branch:
$ svndiff http://svn.python.org/projects/peps/{trunk,branches/jim-update-345}/pep-0345.txt $ svn log --stop-on-copy http://svn.python.org/projects/peps/branches/jim-update-345 ------------------------------------------------------------------------ r70636 | jim.fulton | 2009-03-27 15:19:28 -0400 (Fri, 27 Mar 2009) | 1 line
Update meta data reflecting work in setuptools
I am not (yet) a Python committer; if I were so blessed, I would be glad to commit this change on that branch.
Also, I am wondering if we shouldn't merge it with PEP 376, where we might want to add a REQUIRES file into the egg.info structure, besides the PKG-INFO file.
I wouldn't chunk those changes: the PEP which specifies the PKG-INFO format needs to have a clear history. If PKG-INFO is extended to hold distribution-level requires / provides / obsoletes, then I can see no reason to add another generated file inside egg-info (which already contains PKG-INFO). Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJ3jD4+gerLs4ltQ4RArsXAJsHcW/cI5hRiuzOQ/zgvIF4SbGoWACeMzMV HWBIMloJDE4OE+UQI3zxaWo= =i/wZ -----END PGP SIGNATURE-----
On Thu, Apr 9, 2009 at 7:31 PM, Tres Seaver <tseaver@palladion.com> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Tarek Ziadé wrote:
Jim started a branch during Pycon, maybe you can push your work over there for review here ?
AFAICT, Jim hasn't checked anything into that branch:
$ svndiff http://svn.python.org/projects/peps/{trunk,branches/jim-update-345}/pep-0345.txt $ svn log --stop-on-copy http://svn.python.org/projects/peps/branches/jim-update-345 ------------------------------------------------------------------------ r70636 | jim.fulton | 2009-03-27 15:19:28 -0400 (Fri, 27 Mar 2009) | 1 line
Update meta data reflecting work in setuptools
I am not (yet) a Python committer; if I were so blessed, I would be glad to commit this change on that branch.
ok, maybe you can push it to the wiki then, and I'll commit it when it's ready ?
Also, I am wondering if we shouldn't merge it with PEP 376, where we might want to add a REQUIRES file into the egg.info structure, besides the PKG-INFO file.
I wouldn't chunk those changes: the PEP which specifies the PKG-INFO format needs to have a clear history.
If PKG-INFO is extended to hold distribution-level requires / provides / obsoletes, then I can see no reason to add another generated file inside egg-info (which already contains PKG-INFO).
Because setuptools does it. It adds a requires.txt file separated from PKG-INFO. But it would make sense not to have a second file. Tarek
Hi, I might be late and I haven't been to pycon but I've noted in this pep 345: It is an attempt to re-invent the rpm spec file? In this case how would you plan to integrate with the rpms dependecies? Let me provide an usage scenario for packaging a generic rpm ("foobar" from now on) depending on another python module (let's call it "depend"): 1. user "build" his/her install a *local* version of "depend" in order to build "foobar" 2. the building of the "foobar" rpm succeed because the "depend" is installed (although locally) 3. "build" gives his rpm generated (and possibly the srpms) to the network administrator for deployment At this point I see two problems: 1. the administrator installs "foobar" assuming that won't fail (runtime error) 2. the administrator tries to rebuild "foobar" from the srpm (build time error) In both case the administrator will blame "build" because: 1. The developer relying on "foobar" cannot start it (missing dependency "depend") 2. The administrator cannot rebuild "foobar" because "depends" is not installed The problem is excacerbated by the fact that rpm has already a dependecy checker (as yum/yast/smart and other tools make use of this) and it won't see the "PKG_INFO" dependencies. Regards, Antonio On Thu, Apr 9, 2009 at 7:06 PM, Tarek Ziadé <ziade.tarek@gmail.com> wrote:
On Thu, Apr 9, 2009 at 7:31 PM, Tres Seaver <tseaver@palladion.com> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Tarek Ziadé wrote:
Jim started a branch during Pycon, maybe you can push your work over there for review here ?
AFAICT, Jim hasn't checked anything into that branch:
$ svndiff http://svn.python.org/projects/peps/{trunk,branches/jim-update-345}/pep-0345.txt $ svn log --stop-on-copy http://svn.python.org/projects/peps/branches/jim-update-345 ------------------------------------------------------------------------ r70636 | jim.fulton | 2009-03-27 15:19:28 -0400 (Fri, 27 Mar 2009) | 1 line
Update meta data reflecting work in setuptools
I am not (yet) a Python committer; if I were so blessed, I would be glad to commit this change on that branch.
ok, maybe you can push it to the wiki then, and I'll commit it when it's ready ?
Also, I am wondering if we shouldn't merge it with PEP 376, where we might want to add a REQUIRES file into the egg.info structure, besides the PKG-INFO file.
I wouldn't chunk those changes: the PEP which specifies the PKG-INFO format needs to have a clear history.
If PKG-INFO is extended to hold distribution-level requires / provides / obsoletes, then I can see no reason to add another generated file inside egg-info (which already contains PKG-INFO).
Because setuptools does it. It adds a requires.txt file separated from PKG-INFO. But it would make sense not to have a second file.
Tarek _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Antonio Cavallo wrote:
I might be late and I haven't been to pycon but I've noted in this pep 345:
It is an attempt to re-invent the rpm spec file?
No, it is an attempt to provide Python-specific information about a package in a machine-readable format, which doesn't require running 'setup()'. This information will be present in 'sdist' and 'bdist*' archives, as well as in installed packages. Once landed, we can look at how layers like setuptools, as well as the catalog (PyPI) can exploit this information.
In this case how would you plan to integrate with the rpms dependecies?
Not at all. There is no guarantee that we know about or can satisfy the policies of arbitrary distributions. We hope that adding dependency information which is targeted at distributions rather than importable packages / modules will make life easier for the folks who package our distributions as .rpm, .deb, etc. E.g., packagers might be able to write tools which query this data and then generate the files which match their policies, mapping distribution names, etc. Note that PEP 314, which is already landed, added dependency-related fields ('Requires', 'Provides', 'Obsoletes') but specified a semantic for them which is not as useful (the names in those fields are supposed to be names of importable packages or modules, rather than distutils project names). There are some packages in PyPI already which spell these fields, but there is no practical way to *use* them in any automated way. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJ3kFn+gerLs4ltQ4RAlZQAJ9SVqFlxwpO5yUA7sOYyaWkvHxUAACggX8e s+JEFb51SYLRt9JFzBRQuG8= =XI4H -----END PGP SIGNATURE-----
On Apr 9, 2009, at 12:55 PM, Tres Seaver wrote: ...
I have backed off on the notion of overloading 'Requires:' / 'Provides:' / 'Obsoletes:', following Jim's notion of deprecating them in favor of new fields. I named them 'Requires-Dist:', 'Provides-Dist:', and 'Obsoletes-Dist'.
"Stock" distutils should probably spell the arguments to distutils.core.setup predictably: 'requires_dist', 'provides_dist', 'obsoletes_dist'. setuptools can treat 'install_requires' as an undeprecated alias for 'requires_dist'.
What is the rational for this? I'd strongly prefer the "requires" argument name to be compatible with setuptools. Otherwise, I think we'll introduce needless confusion. Jim -- Jim Fulton Zope Corporation
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jim Fulton wrote:
On Apr 9, 2009, at 12:55 PM, Tres Seaver wrote: ...
I have backed off on the notion of overloading 'Requires:' / 'Provides:' / 'Obsoletes:', following Jim's notion of deprecating them in favor of new fields. I named them 'Requires-Dist:', 'Provides-Dist:', and 'Obsoletes-Dist'.
"Stock" distutils should probably spell the arguments to distutils.core.setup predictably: 'requires_dist', 'provides_dist', 'obsoletes_dist'. setuptools can treat 'install_requires' as an undeprecated alias for 'requires_dist'.
What is the rational for this? I'd strongly prefer the "requires" argument name to be compatible with setuptools. Otherwise, I think we'll introduce needless confusion.
I'm aiming for self-consistency within the 'PKG-INFO' field names: - 'Requires' - 'Requires-Python' - 'Requires-External' The 'Obsoletes' and 'Provides' fields also need distutils-project-oriented versions, so picking a suffix ('-Dist') which matched for them seemed cleanest. Add that to the fact that setuptools has no way (yet) to spell 'provides' or 'obsoletes', and it seemed to me clearer to just make setuptools current argument an alias for the "consistent" version to be landed in distutils. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJ3nlW+gerLs4ltQ4RAqnHAKCn033qJCe7iuV0uzBWVXlnAQiqfwCgzX2F L0rqU3Z7jC4ftYrSHnToLH4= =umR3 -----END PGP SIGNATURE-----
On Apr 9, 2009, at 6:40 PM, Tres Seaver wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Jim Fulton wrote:
On Apr 9, 2009, at 12:55 PM, Tres Seaver wrote: ...
I have backed off on the notion of overloading 'Requires:' / 'Provides:' / 'Obsoletes:', following Jim's notion of deprecating them in favor of new fields. I named them 'Requires-Dist:', 'Provides-Dist:', and 'Obsoletes-Dist'.
"Stock" distutils should probably spell the arguments to distutils.core.setup predictably: 'requires_dist', 'provides_dist', 'obsoletes_dist'. setuptools can treat 'install_requires' as an undeprecated alias for 'requires_dist'.
What is the rational for this? I'd strongly prefer the "requires" argument name to be compatible with setuptools. Otherwise, I think we'll introduce needless confusion.
I'm aiming for self-consistency within the 'PKG-INFO' field names:
- 'Requires' - 'Requires-Python' - 'Requires-External'
The 'Obsoletes' and 'Provides' fields also need distutils-project-oriented versions, so picking a suffix ('-Dist') which matched for them seemed cleanest.
Add that to the fact that setuptools has no way (yet) to spell 'provides' or 'obsoletes', and it seemed to me clearer to just make setuptools current argument an alias for the "consistent" version to be landed in distutils.
I get that. In fact, I already got that. :) I think backward compatibility with existing wide usage is more important and not incompatible. So then I suggest we change the field and option names to (adjusting capitalization as necessary): install_requires, install_provides, and install_obsoletes. I'm a very strong -1 to requires_dist. Jim -- Jim Fulton Zope Corporation
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jim Fulton wrote:
On Apr 9, 2009, at 6:40 PM, Tres Seaver wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Jim Fulton wrote:
On Apr 9, 2009, at 12:55 PM, Tres Seaver wrote: ...
I have backed off on the notion of overloading 'Requires:' / 'Provides:' / 'Obsoletes:', following Jim's notion of deprecating them in favor of new fields. I named them 'Requires-Dist:', 'Provides-Dist:', and 'Obsoletes-Dist'.
"Stock" distutils should probably spell the arguments to distutils.core.setup predictably: 'requires_dist', 'provides_dist', 'obsoletes_dist'. setuptools can treat 'install_requires' as an undeprecated alias for 'requires_dist'.
What is the rational for this? I'd strongly prefer the "requires" argument name to be compatible with setuptools. Otherwise, I think we'll introduce needless confusion. I'm aiming for self-consistency within the 'PKG-INFO' field names:
- 'Requires' - 'Requires-Python' - 'Requires-External'
The 'Obsoletes' and 'Provides' fields also need distutils-project-oriented versions, so picking a suffix ('-Dist') which matched for them seemed cleanest.
Add that to the fact that setuptools has no way (yet) to spell 'provides' or 'obsoletes', and it seemed to me clearer to just make setuptools current argument an alias for the "consistent" version to be landed in distutils.
I get that. In fact, I already got that. :) I think backward compatibility with existing wide usage is more important and not incompatible.
So then I suggest we change the field and option names to (adjusting capitalization as necessary): install_requires, install_provides, and install_obsoletes.
I'm a very strong -1 to requires_dist.
I think we need to distinguish the spelling of the arguments passed to setup() from the fields written into PKG-INFO. At the moment, there is a very widespread usage of 'install_requires' among setuptools-based packages. How that argument maps onto PKG-INFO fields (which is what PEP 345 is really about) is open to some debate. I think consistency *within* PKG-INFO fieldnames is more important than consistency between setup arguments and the corresponding fieldnames: for instance, distutils.core.setup already defiens a 'url' argument, which maps onto 'Homepage-URL' in PKG-INFO. We could use the names you proposed for arguments to 'setup()', and still use the names I proposed for PKG-INFO. There is one more new argument to setup() we should consider, which might be spelled 'build_requires', and which would map onto the 'Requires-External' PKG-INFO field. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJ30dR+gerLs4ltQ4RAhYHAKDY971Z0WOVGWMWUaGML42ByTNguwCfb5gX a6/EZb+J/4T+XgtMBSoCgLs= =rhm+ -----END PGP SIGNATURE-----
On Fri, Apr 10, 2009 at 09:19:13AM -0400, Tres Seaver wrote:
There is one more new argument to setup() we should consider, which might be spelled 'build_requires', and which would map onto the 'Requires-External' PKG-INFO field.
Setuptools has a 'setup_requires' argument to setup(). I don't know if the semantics of that one are similar to your proposed 'build_requires'. Marius Gedminas -- Truth does not demand belief. Scientists do not join hands every Sunday, singing, 'Yes, gravity is real! I will have faith! I will be strong! I believe in my heart that what goes up, up, up must come down, down, down. Amen!' If they did, we would think they were pretty insecure about it. - Dan Barker
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Marius Gedminas wrote:
On Fri, Apr 10, 2009 at 09:19:13AM -0400, Tres Seaver wrote:
There is one more new argument to setup() we should consider, which might be spelled 'build_requires', and which would map onto the 'Requires-External' PKG-INFO field.
Setuptools has a 'setup_requires' argument to setup(). I don't know if the semantics of that one are similar to your proposed 'build_requires'.
Nope: 'build_requires' is something Matthias Klose discussed as being useful for downstream packagers: it doesn't refer to Python distributions, but to external library / tool requriements. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJ31Bf+gerLs4ltQ4RAmduAJwPAQftvIrNdSkImZgG469WJ45dGwCgm+Aj 4BXZ6Jo4HZDSlETKsYxrPAM= =Jqm3 -----END PGP SIGNATURE-----
Tres Seaver wrote:
Marius Gedminas wrote:
There is one more new argument to setup() we should consider, which might be spelled 'build_requires', and which would map onto the 'Requires-External' PKG-INFO field. Setuptools has a 'setup_requires' argument to setup(). I don't know if
On Fri, Apr 10, 2009 at 09:19:13AM -0400, Tres Seaver wrote: the semantics of that one are similar to your proposed 'build_requires'.
Nope: 'build_requires' is something Matthias Klose discussed as being useful for downstream packagers: it doesn't refer to Python distributions, but to external library / tool requriements.
It could still be useful to python as well, for a potential future tool. That's very useful for bootstrapping packages, for example, so it is not just for downstream packagers. @Marius: build-requires spells out the dependencies necessary to *build* the concerned package, but which are not necessary to *use* the package. For example, a python package foo requires paver to be built correctly, but you can use foo in your own code without paver. cheers, David
On Fri, Apr 10, 2009 at 10:49:36PM +0900, David Cournapeau wrote:
Tres Seaver wrote:
Marius Gedminas wrote:
There is one more new argument to setup() we should consider, which might be spelled 'build_requires', and which would map onto the 'Requires-External' PKG-INFO field. Setuptools has a 'setup_requires' argument to setup(). I don't know if
On Fri, Apr 10, 2009 at 09:19:13AM -0400, Tres Seaver wrote: the semantics of that one are similar to your proposed 'build_requires'.
Nope: 'build_requires' is something Matthias Klose discussed as being useful for downstream packagers: it doesn't refer to Python distributions, but to external library / tool requriements.
It could still be useful to python as well, for a potential future tool. That's very useful for bootstrapping packages, for example, so it is not just for downstream packagers.
@Marius: build-requires spells out the dependencies necessary to *build* the concerned package, but which are not necessary to *use* the package. For example, a python package foo requires paver to be built correctly, but you can use foo in your own code without paver.
And that's exactly how setup_requires differs from install_requires, which prompted my question. ;-) Tres's answer explains it all (except for the syntax, which I should go and look up if I'm interested, I suppose). Marius Gedminas -- This sentence contradicts itself -- no actually it doesn't. -- Douglas Hofstadter
On Fri, Apr 10, 2009 at 2:30 PM, Jim Fulton <jim@zope.com> wrote:
On Apr 9, 2009, at 6:40 PM, Tres Seaver wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Jim Fulton wrote:
On Apr 9, 2009, at 12:55 PM, Tres Seaver wrote: ...
I have backed off on the notion of overloading 'Requires:' / 'Provides:' / 'Obsoletes:', following Jim's notion of deprecating them in favor of new fields. I named them 'Requires-Dist:', 'Provides-Dist:', and 'Obsoletes-Dist'.
"Stock" distutils should probably spell the arguments to distutils.core.setup predictably: 'requires_dist', 'provides_dist', 'obsoletes_dist'. setuptools can treat 'install_requires' as an undeprecated alias for 'requires_dist'.
What is the rational for this? I'd strongly prefer the "requires" argument name to be compatible with setuptools. Otherwise, I think we'll introduce needless confusion.
I'm aiming for self-consistency within the 'PKG-INFO' field names:
- 'Requires' - 'Requires-Python' - 'Requires-External'
The 'Obsoletes' and 'Provides' fields also need distutils-project-oriented versions, so picking a suffix ('-Dist') which matched for them seemed cleanest.
Add that to the fact that setuptools has no way (yet) to spell 'provides' or 'obsoletes', and it seemed to me clearer to just make setuptools current argument an alias for the "consistent" version to be landed in distutils.
I get that. In fact, I already got that. :) I think backward compatibility with existing wide usage is more important and not incompatible.
we could also support both spellings for one version, and deprecate the old name with a warning, Tarek
On Apr 10, 2009, at 10:30 AM, Tarek Ziadé wrote:
On Fri, Apr 10, 2009 at 2:30 PM, Jim Fulton <jim@zope.com> wrote:
On Apr 9, 2009, at 6:40 PM, Tres Seaver wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Jim Fulton wrote:
On Apr 9, 2009, at 12:55 PM, Tres Seaver wrote: ...
I have backed off on the notion of overloading 'Requires:' / 'Provides:' / 'Obsoletes:', following Jim's notion of deprecating them in favor of new fields. I named them 'Requires-Dist:', 'Provides-Dist:', and 'Obsoletes-Dist'.
"Stock" distutils should probably spell the arguments to distutils.core.setup predictably: 'requires_dist', 'provides_dist', 'obsoletes_dist'. setuptools can treat 'install_requires' as an undeprecated alias for 'requires_dist'.
What is the rational for this? I'd strongly prefer the "requires" argument name to be compatible with setuptools. Otherwise, I think we'll introduce needless confusion.
I'm aiming for self-consistency within the 'PKG-INFO' field names:
- 'Requires' - 'Requires-Python' - 'Requires-External'
The 'Obsoletes' and 'Provides' fields also need distutils-project-oriented versions, so picking a suffix ('-Dist') which matched for them seemed cleanest.
Add that to the fact that setuptools has no way (yet) to spell 'provides' or 'obsoletes', and it seemed to me clearer to just make setuptools current argument an alias for the "consistent" version to be landed in distutils.
I get that. In fact, I already got that. :) I think backward compatibility with existing wide usage is more important and not incompatible.
we could also support both spellings for one version, and deprecate the old name with a warning,
Strong: -1. Why change the name? A different name isn't going to be better enough to be worth the hassle. Deprecation is waaaay overrated as a tool for reducing the pain of making people change their code or habits. Jim -- Jim Fulton Zope Corporation
On Fri, Apr 10, 2009 at 4:33 PM, Jim Fulton <jim@zope.com> wrote:
On Apr 10, 2009, at 10:30 AM, Tarek Ziadé wrote:
On Fri, Apr 10, 2009 at 2:30 PM, Jim Fulton <jim@zope.com> wrote:
On Apr 9, 2009, at 6:40 PM, Tres Seaver wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Jim Fulton wrote:
On Apr 9, 2009, at 12:55 PM, Tres Seaver wrote: ...
I have backed off on the notion of overloading 'Requires:' / 'Provides:' / 'Obsoletes:', following Jim's notion of deprecating them in favor of new fields. I named them 'Requires-Dist:', 'Provides-Dist:', and 'Obsoletes-Dist'.
"Stock" distutils should probably spell the arguments to distutils.core.setup predictably: 'requires_dist', 'provides_dist', 'obsoletes_dist'. setuptools can treat 'install_requires' as an undeprecated alias for 'requires_dist'.
What is the rational for this? I'd strongly prefer the "requires" argument name to be compatible with setuptools. Otherwise, I think we'll introduce needless confusion.
I'm aiming for self-consistency within the 'PKG-INFO' field names:
- 'Requires' - 'Requires-Python' - 'Requires-External'
The 'Obsoletes' and 'Provides' fields also need distutils-project-oriented versions, so picking a suffix ('-Dist') which matched for them seemed cleanest.
Add that to the fact that setuptools has no way (yet) to spell 'provides' or 'obsoletes', and it seemed to me clearer to just make setuptools current argument an alias for the "consistent" version to be landed in distutils.
I get that. In fact, I already got that. :) I think backward compatibility with existing wide usage is more important and not incompatible.
we could also support both spellings for one version, and deprecate the old name with a warning,
Strong: -1.
Why change the name? A different name isn't going to be better enough to be worth the hassle. Deprecation is waaaay overrated as a tool for reducing the pain of making people change their code or habits.
I don't think it's a good idea to have a different name in PKG-INFO and in the arguments to describe the same element. we should have the same name everywhere for consistency at the end. I don't see anything wrong about adding a simple deprecation warning here, It won't happen again for quite a while. Distutils already had some argument name changes like that for backward compatiblity (licence<->license) but they were not displaying any warning. OTHO I'd be fine if the current setuptool name is used in PKG-INFO
On Apr 10, 2009, at 10:40 AM, Tarek Ziadé wrote:
On Fri, Apr 10, 2009 at 4:33 PM, Jim Fulton <jim@zope.com> wrote:
On Apr 10, 2009, at 10:30 AM, Tarek Ziadé wrote:
On Fri, Apr 10, 2009 at 2:30 PM, Jim Fulton <jim@zope.com> wrote:
On Apr 9, 2009, at 6:40 PM, Tres Seaver wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Jim Fulton wrote:
On Apr 9, 2009, at 12:55 PM, Tres Seaver wrote: ... > > I have backed off on the notion of overloading 'Requires:' / > 'Provides:' > / 'Obsoletes:', following Jim's notion of deprecating them in > favor of > new fields. I named them 'Requires-Dist:', 'Provides-Dist:', > and > 'Obsoletes-Dist'. > > "Stock" distutils should probably spell the arguments to > distutils.core.setup predictably: 'requires_dist', > 'provides_dist', > 'obsoletes_dist'. setuptools can treat 'install_requires' as an > undeprecated alias for 'requires_dist'.
What is the rational for this? I'd strongly prefer the "requires" argument name to be compatible with setuptools. Otherwise, I think we'll introduce needless confusion.
I'm aiming for self-consistency within the 'PKG-INFO' field names:
- 'Requires' - 'Requires-Python' - 'Requires-External'
The 'Obsoletes' and 'Provides' fields also need distutils-project-oriented versions, so picking a suffix ('- Dist') which matched for them seemed cleanest.
Add that to the fact that setuptools has no way (yet) to spell 'provides' or 'obsoletes', and it seemed to me clearer to just make setuptools current argument an alias for the "consistent" version to be landed in distutils.
I get that. In fact, I already got that. :) I think backward compatibility with existing wide usage is more important and not incompatible.
we could also support both spellings for one version, and deprecate the old name with a warning,
Strong: -1.
Why change the name? A different name isn't going to be better enough to be worth the hassle. Deprecation is waaaay overrated as a tool for reducing the pain of making people change their code or habits.
I don't think it's a good idea to have a different name in PKG-INFO and in the arguments to describe the same element. we should have the same name everywhere for consistency at the end.
Argue with Tres. :) He gave an example where setup argument names and meta-data field names were different.
I don't see anything wrong about adding a simple deprecation warning here, It won't happen again for quite a while.
We disagree then. Too often people use deprecation as a way to argue that a change isn't too painful. Sometimes, change is necessary and deprecation helps to manage the change. The change we're talking about isn't necessary. ...
OTHO I'd be fine if the current setuptool name is used in PKG-INFO
Me too. :) Jim -- Jim Fulton Zope Corporation
On Fri, Apr 10, 2009 at 9:40 AM, Tarek Ziadé <ziade.tarek@gmail.com> wrote:
Why change the name? A different name isn't going to be better enough to be worth the hassle. Deprecation is waaaay overrated as a tool for reducing the pain of making people change their code or habits.
I don't think it's a good idea to have a different name in PKG-INFO and in the arguments to describe the same element. we should have the same name everywhere for consistency at the end.
I don't see anything wrong about adding a simple deprecation warning here, It won't happen again for quite a while.
People who install packages freak out over warnings. If you could do a warning during a PyPI upload, then someone who can actually make a change might see it. People installing a package should not see this warning. I feel very strongly about this as a general rule - putting messages intended for packagers into the output presented during installation is distracting and disconcerting and useless. In the "check" command it would be entirely proper to issue a warning. But no one is going to re-release a project just to fix the spelling of this argument in setup.py, and a lot of libraries just don't get updated often, or people deliberately use old versions to avoid regression. So outside of the check command it should not cause any warning. -- Ian Bicking | http://blog.ianbicking.org
On Fri, Apr 10, 2009 at 9:08 PM, Ian Bicking <ianb@colorstudy.com> wrote:
On Fri, Apr 10, 2009 at 9:40 AM, Tarek Ziadé <ziade.tarek@gmail.com> wrote:
Why change the name? A different name isn't going to be better enough to be worth the hassle. Deprecation is waaaay overrated as a tool for reducing the pain of making people change their code or habits.
I don't think it's a good idea to have a different name in PKG-INFO and in the arguments to describe the same element. we should have the same name everywhere for consistency at the end.
I don't see anything wrong about adding a simple deprecation warning here, It won't happen again for quite a while.
People who install packages freak out over warnings. If you could do a warning during a PyPI upload, then someone who can actually make a change might see it. People installing a package should not see this warning. I feel very strongly about this as a general rule - putting messages intended for packagers into the output presented during installation is distracting and disconcerting and useless.
In the "check" command it would be entirely proper to issue a warning. But no one is going to re-release a project just to fix the spelling of this argument in setup.py, and a lot of libraries just don't get updated often, or people deliberately use old versions to avoid regression. So outside of the check command it should not cause any warning.
Right, sounds like
-- Ian Bicking | http://blog.ianbicking.org
-- Tarek Ziadé | Association AfPy | www.afpy.org Blog FR | http://programmation-python.org Blog EN | http://tarekziade.wordpress.com/
On Sat, Apr 11, 2009 at 3:33 PM, Tarek Ziadé <ziade.tarek@gmail.com> wrote:
I don't see anything wrong about adding a simple deprecation warning here, It won't happen again for quite a while.
People who install packages freak out over warnings. If you could do a warning during a PyPI upload, then someone who can actually make a change might see it. People installing a package should not see this warning. I feel very strongly about this as a general rule - putting messages intended for packagers into the output presented during installation is distracting and disconcerting and useless.
In the "check" command it would be entirely proper to issue a warning. But no one is going to re-release a project just to fix the spelling of this argument in setup.py, and a lot of libraries just don't get updated often, or people deliberately use old versions to avoid regression. So outside of the check command it should not cause any warning.
Right, sounds like
oups, send it too early Right, sounds like a good practice. So what shall we do for install_requires ? I'd be in favor of : - keeping the new PKG-INFO Tres proposed - maintaining both setup() arguments (like license and licence) - documenting the new argument - adding the warning in the 'check' command Cheers Tarek
On Sat, Apr 11, 2009 at 3:38 PM, Tarek Ziadé <ziade.tarek@gmail.com> wrote:
Right, sounds like a good practice.
So what shall we do for install_requires ?
I'd be in favor of :
- keeping the new PKG-INFO Tres proposed - maintaining both setup() arguments (like license and licence) - documenting the new argument - adding the warning in the 'check' command
(unless everyone is fine with having a install_requires argument and a different PKG-INFO field)
On Apr 11, 2009, at 10:09 AM, Tarek Ziadé wrote:
On Sat, Apr 11, 2009 at 3:38 PM, Tarek Ziadé <ziade.tarek@gmail.com> wrote:
Right, sounds like a good practice.
So what shall we do for install_requires ?
I'd be in favor of :
- keeping the new PKG-INFO Tres proposed - maintaining both setup() arguments (like license and licence) - documenting the new argument - adding the warning in the 'check' command
(unless everyone is fine with having a install_requires argument and a different PKG-INFO field)
I'd prefer that to having 2 arguments that mean the same thing. fwiw, I'd also prefer calling the PKG-INFO field Install-Requires. Jim -- Jim Fulton Zope Corporation
On Apr 11, 2009, at 8:13 AM, Jim Fulton wrote:
fwiw, I'd also prefer calling the PKG-INFO field Install-Requires.
+1 from me. I was just browsing pypi, and there seem to be many tools out there which are designed to work with the current egg metadata. The fewer unnecessary name-changes we impose, the more likely the authors of all those tools will update their tools to interoperate with the new Distutils. Speaking of which, the proposed 'build_requires' seems to be somewhat similar to setuptools's 'setup_requires'. The difference seems to be that 'build_requires' is intended for non-Python tools and 'setup_requires' currently works only for Python packages ("distributions"). Regards, Zooko
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 zooko wrote:
On Apr 11, 2009, at 8:13 AM, Jim Fulton wrote:
fwiw, I'd also prefer calling the PKG-INFO field Install-Requires.
+1 from me.
I was just browsing pypi, and there seem to be many tools out there which are designed to work with the current egg metadata. The fewer unnecessary name-changes we impose, the more likely the authors of all those tools will update their tools to interoperate with the new Distutils.
None of them are working with any dependency-based PKG-INFO fields, becuase there is no useful information in those fields. Some of them may be working with arguments passed to 'setup()' (e.g., by running 'egg-info' in a tempdir and parsing the setuptools-specific files), but such tools will have to be changed anyway (e.g., to use the new PKG-INFO fields instead of parsing requries.txt).
Speaking of which, the proposed 'build_requires' seems to be somewhat similar to setuptools's 'setup_requires'. The difference seems to be that 'build_requires' is intended for non-Python tools and 'setup_requires' currently works only for Python packages ("distributions").
Correct. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJ4hF8+gerLs4ltQ4RApg/AKCQy7YFO0qj2e8dLIwbdP47NOzG7ACgkLIL ImQeogWLYTUUAjqFvDUkKZQ= =2Ukp -----END PGP SIGNATURE-----
On Apr 12, 2009, at 10:06 AM, Tres Seaver wrote:
... there seem to be many tools out there which are designed to work with the current egg metadata. The fewer unnecessary name- changes we impose, the more likely the authors of all those tools will update their tools to interoperate with the new Distutils.
None of them are working with any dependency-based PKG-INFO fields, ... Some of them may be working with arguments passed to 'setup ()' (e.g., by running 'egg-info' in a tempdir and parsing the setuptools-specific files), but such tools will have to be changed anyway (e.g., to use the new PKG-INFO fields instead of parsing requries.txt).
That makes sense. What I said wasn't that the tools would automatically interoperate, rather that using the same name would make it easier for those authors to start supporting the New Distutils. However, I think I've expressed my opinion on the issue with sufficient thoroughness that I can now leave the decision up to you. Regards, Zooko
Tarek Ziadé wrote:
I don't think it's a good idea to have a different name in PKG-INFO and in the arguments to describe the same element. we should have the same name everywhere for consistency at the end.
I don't see anything wrong about adding a simple deprecation warning here, It won't happen again for quite a while.
Distutils already had some argument name changes like that for backward compatiblity (licence<->license) but they were not displaying any warning.
What would be the problem with having both sets work and not deprecate either? (ie: make them synonyms of each other?) cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
On Apr 11, 2009, at 8:20 AM, Chris Withers wrote:
Tarek Ziadé wrote:
I don't think it's a good idea to have a different name in PKG-INFO and in the arguments to describe the same element. we should have the same name everywhere for consistency at the end. I don't see anything wrong about adding a simple deprecation warning here, It won't happen again for quite a while. Distutils already had some argument name changes like that for backward compatiblity (licence<->license) but they were not displaying any warning.
What would be the problem with having both sets work and not deprecate either? (ie: make them synonyms of each other?)
It violates toowtdi. Jim -- Jim Fulton Zope Corporation
Jim Fulton wrote:
On Apr 11, 2009, at 8:20 AM, Chris Withers wrote:
Tarek Ziadé wrote:
I don't think it's a good idea to have a different name in PKG-INFO and in the arguments to describe the same element. we should have the same name everywhere for consistency at the end. I don't see anything wrong about adding a simple deprecation warning here, It won't happen again for quite a while. Distutils already had some argument name changes like that for backward compatiblity (licence<->license) but they were not displaying any warning.
What would be the problem with having both sets work and not deprecate either? (ie: make them synonyms of each other?)
It violates toowtdi.
*shrugs* It's not duplicating code, and if it stops another 200 message thread on python-dev, I'm pretty sure we can live with it ;-) Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jim Fulton wrote:
On Apr 11, 2009, at 8:20 AM, Chris Withers wrote:
Tarek Ziadé wrote:
I don't think it's a good idea to have a different name in PKG-INFO and in the arguments to describe the same element. we should have the same name everywhere for consistency at the end. I don't see anything wrong about adding a simple deprecation warning here, It won't happen again for quite a while. Distutils already had some argument name changes like that for backward compatiblity (licence<->license) but they were not displaying any warning. What would be the problem with having both sets work and not deprecate either? (ie: make them synonyms of each other?)
It violates toowtdi.
BBB concerns often trump TOOWTDI. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJ4Ny9+gerLs4ltQ4RArIhAJ0YVl/MHK/MJENRd/aF2LcN/x5O3QCgppbL rfhjfh+M5DRRgAFdRBoOa0M= =X6S7 -----END PGP SIGNATURE-----
On Apr 11, 2009, at 2:09 PM, Tres Seaver wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Jim Fulton wrote:
On Apr 11, 2009, at 8:20 AM, Chris Withers wrote:
Tarek Ziadé wrote:
I don't think it's a good idea to have a different name in PKG-INFO and in the arguments to describe the same element. we should have the same name everywhere for consistency at the end. I don't see anything wrong about adding a simple deprecation warning here, It won't happen again for quite a while. Distutils already had some argument name changes like that for backward compatiblity (licence<->license) but they were not displaying any warning. What would be the problem with having both sets work and not deprecate either? (ie: make them synonyms of each other?)
It violates toowtdi.
BBB concerns often trump TOOWTDI.
Sure, but there's no BBB concern here -- unless we create one. Jim -- Jim Fulton Zope Corporation
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jim Fulton wrote:
On Apr 11, 2009, at 2:09 PM, Tres Seaver wrote:
BBB concerns often trump TOOWTDI.
Sure, but there's no BBB concern here -- unless we create one.
Your desire to preserve the 'install_requires' argument feels like a backward-compatibility requirement to me (and one which I'm fine with keeping indefinitely). You have a separate desire, which is to use the spelling 'Install-Requires' for the PKG-INFO field corresponding to 'install_requires'. I would prefer to keep the names close to those already proposed in PEP 345 ('Requries-External', 'Requires-Python'). My desire is to keep the PKG-INFO specification and field names clean and internally consistent: there is no BBB concern here, because the existing 'Requires:' field won't be touched (although we will deprecate it). Keeping the fieldnames consistent within that file seems more important to me than an (already violated) expectation that setup() argument names map mechanically onto PKG-INFO field names. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJ4g0A+gerLs4ltQ4RAs9gAKDGhLB69nyrBT0jQ5tkhHheP8hJLwCgsOO+ 3LgxigdTWW+MYTaBEWziDlk= =ymHa -----END PGP SIGNATURE-----
On Sun, Apr 12, 2009 at 5:47 PM, Tres Seaver <tseaver@palladion.com> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Jim Fulton wrote:
On Apr 11, 2009, at 2:09 PM, Tres Seaver wrote:
BBB concerns often trump TOOWTDI.
Sure, but there's no BBB concern here -- unless we create one.
Your desire to preserve the 'install_requires' argument feels like a backward-compatibility requirement to me (and one which I'm fine with keeping indefinitely). You have a separate desire, which is to use the spelling 'Install-Requires' for the PKG-INFO field corresponding to 'install_requires'. I would prefer to keep the names close to those already proposed in PEP 345 ('Requries-External', 'Requires-Python').
My desire is to keep the PKG-INFO specification and field names clean and internally consistent: there is no BBB concern here, because the existing 'Requires:' field won't be touched (although we will deprecate it). Keeping the fieldnames consistent within that file seems more important to me than an (already violated) expectation that setup() argument names map mechanically onto PKG-INFO field names.
While there's no bijection between the arguments and the PKG-INFO fields, some arguments *are* PKG-INFO fields; If we would start a package from scratch today, what we would have for thos ? probably the same name for the argument and the field. What I hear here is that since we don't start from scratch we have to compromise on consistency so we don't bather with BBB. But the goal is also to make Distutils a better citizen in this area *and* to use the best name. And some people in the future might not understand why they can't use "requires_dist" in the arguments, like they use "classifiers" and "author", and they will find it rather strange if we tell them "This is for historical reason !" So, while I perfectly understand Jim and Tres points, I do think we need to have an argument that matches the PKG-INFO field name, even if it's doubled with another one. Cheers Tarek
On Apr 9, 2009, at 16:40 PM, Tres Seaver wrote:
Jim Fulton wrote:
On Apr 9, 2009, at 12:55 PM, Tres Seaver wrote:
setuptools can treat 'install_requires' as an undeprecated alias for 'requires_dist'.
What is the rational for this? I'd strongly prefer the "requires" argument name to be compatible with setuptools. Otherwise, I think we'll introduce needless confusion.
I'm aiming for self-consistency within the 'PKG-INFO' field names:
The easier we can make it for The New Distutils to be compatible with existing and widely used [1] setuptools and easy_install the better. To the extent that you can suffer a little bit of ugliness or variation in the New Distutils in order to ease compatibility, I would be very grateful if you would do so. For example, what if I want to run "easy_install http://example.com/ foo.tar.gz", where foo is packaged with the New Distutils? This currently works with the Old Distutils, but foo is unable to declare its dependencies on the "bar" distribution using the Old Distutils. It also currently works if foo was packaged with setuptools. The biggest (to my mind) single improvement in the New Distutils is that if foo is packaged with the New Distutils then foo is able to declare its dependency on "bar". Would it be nice if it spelled it in a way that was intelligible to the current crop widely-deployed tools? It will be easier for people to make things like that work if you don't change the names of things unnecessarily. Regards, Zooko [1] http://tarekziade.wordpress.com/2009/03/26/packaging-survey-first- results
participants (9)
-
Antonio Cavallo -
Chris Withers -
David Cournapeau -
Ian Bicking -
Jim Fulton -
Marius Gedminas -
Tarek Ziadé -
Tres Seaver -
zooko