distribute and buildout: best practices?
What's the current best way to use both distribute and buildout? Apart from the bootstrap + apparently needed change in buildout, I've got the following questions: - Do my libraries have to list a dependency on distribute or on setuptools? Everything zopish has a 'setuptools >= 0.6c9' in it. I tried putting distribute in there, but I seemed to get less problems with leaving it at setuptools. - Should just globally installing distribute be enough? Everything ought to keep working. It does lead to a bunch of runtime warnings in buildout, however. (But Tarek has targeted that problem for the upcoming 0.6.4 :-) - Do I need to change buildout's bootstrap already? Doing that tries to change my global setuptools, for which you need to sudo. And it also forces everyone else using that buildout to switch (which in itself is OK). - From my experiments (not exhaustive! no real debugging!) it seems that the only safe way is to first install distribute globally before touching a buildout that brings in distribute. Is this to be expected? Reinout -- Reinout van Rees - reinout@vanrees.org - http://reinout.vanrees.org Software developer at http://www.thehealthagency.com "Military engineers build missiles. Civil engineers build targets"
On Wed, Oct 7, 2009 at 1:23 PM, Reinout van Rees <reinout@vanrees.org> wrote:
What's the current best way to use both distribute and buildout? Apart from the bootstrap + apparently needed change in buildout, I've got the following questions:
- Do my libraries have to list a dependency on distribute or on setuptools? Everything zopish has a 'setuptools >= 0.6c9' in it. I tried putting distribute in there, but I seemed to get less problems with leaving it at setuptools.
No. Once we've resolved the problem you've mentioned in the hardcoded setuptools dependency, you will have an empty Setuptools 0.6c9 egg in eggs/ so libs that ask for this dependency will think it's met.
- Should just globally installing distribute be enough? Everything ought to keep working. It does lead to a bunch of runtime warnings in buildout, however. (But Tarek has targeted that problem for the upcoming 0.6.4 :-)
We still require a specific zc.buildout bootstrap.py, otherwise you will have a local setuptools egg that will override any global installation.
- Do I need to change buildout's bootstrap already? Doing that tries to change my global setuptools, for which you need to sudo. And it also forces everyone else using that buildout to switch (which in itself is OK).
It shouldn't touch anything outside your buildout, please try with the latest one at buildout-distribute at bitbucket.
- From my experiments (not exhaustive! no real debugging!) it seems that the only safe way is to first install distribute globally before touching a buildout that brings in distribute. Is this to be expected?
The Distribute installation will try to patch any setuptools found in the path so it doesn't interfer. In a buildout environment, if it changes anything globally, it's a bug of our patching code and not intended, unless your buildout environment, somehow, uses a global setuptools. But I don't think this can happen. Tarek -- Tarek Ziadé | http://ziade.org | オープンソースはすごい! | 开源传万世，因有你参与
On 2009-10-07, Tarek Ziadé <ziade.tarek@gmail.com> wrote:
On Wed, Oct 7, 2009 at 1:23 PM, Reinout van Rees <reinout@vanrees.org> wrote:
- Do my libraries have to list a dependency on distribute or on setuptools? Everything zopish has a 'setuptools >= 0.6c9' in it. I tried putting distribute in there, but I seemed to get less problems with leaving it at setuptools.
No. Once we've resolved the problem you've mentioned in the hardcoded setuptools dependency, you will have an empty Setuptools 0.6c9 egg in eggs/ so libs that ask for this dependency will think it's met.
But to actually use distribute you need to depend on it somewhere, obviously. Otherwise I only get a setuptools egg in my path.
It shouldn't touch anything outside your buildout, please try with the latest one at buildout-distribute at bitbucket.
The latest bootstrap behaves itself wonderfully. So: once we have new zc.buildout + bootstrap it ought to be safe to change all buildouts without inconveniencing anyone. I'm still not 100% sure whether it is safe to put "distribute" in the install_requires list of a package right now, however. Reinout -- Reinout van Rees - reinout@vanrees.org - http://reinout.vanrees.org Software developer at http://www.thehealthagency.com "Military engineers build missiles. Civil engineers build targets"
On Wed, Oct 7, 2009 at 2:32 PM, Reinout van Rees <reinout@vanrees.org> wrote:
I'm still not 100% sure whether it is safe to put "distribute" in the install_requires list of a package right now, however.
It depends on what you mean by safe. (beside any bootstraping bug we might find in the near future, even if this code seems stabilized now) Adding distribute in install_requires will have the effect of calling the Distribute setup.py and renaming an existing setuptools installation detected in the environment so it doesn't get on the way, and to add a setuptools*.egg-info in the environment so the Setuptools dependency is still met (to avoid Distribute to be overriden in turn) By "environment" I mean here the sys.path than gets scanned by pkg_resources when looking for Distributions. So when your package is installed, its impact will depend on the environment its setup.py was called in. The impact is : now the environment is using Distribute. This has to be done manually in Distribute's setup.py because the micro-dependency managment system provided by easy_install and pkg_resources doesn't know how to deal with mutual exclusive dependencies or interchangeable dependency. But this is not a new problem: if you add dependencies in your distribution, you are impacting the whole execution environment, for every other distribution. Now you can say it outloud in your distribution documentation, that your distribution requires Distribute because it has more bugfixes. Tarek -- Tarek Ziadé | http://ziade.org | オープンソースはすごい! | 开源传万世，因有你参与
On 2009-10-07, Tarek Ziadé <ziade.tarek@gmail.com> wrote:
On Wed, Oct 7, 2009 at 2:32 PM, Reinout van Rees <reinout@vanrees.org> wrote:
I'm still not 100% sure whether it is safe to put "distribute" in the install_requires list of a package right now, however.
It depends on what you mean by safe. (beside any bootstraping bug we might find in the near future, even if this code seems stabilized now)
Adding distribute in install_requires will have the effect of calling the Distribute setup.py and renaming an existing setuptools installation detected in the environment so it doesn't get on the way, and to add a setuptools*.egg-info in the environment so the Setuptools dependency is still met (to avoid Distribute to be overriden in turn)
By "environment" I mean here the sys.path than gets scanned by pkg_resources when looking for Distributions.
So when your package is installed, its impact will depend on the environment its setup.py was called in.
The impact is : now the environment is using Distribute.
Ok, I've experimented some more and came to some sort of conclusion in the bug report: http://tinyurl.com/yaa23yl The warning problem occurs if the environment (which you mention above) uses distribute. This environment could be a buildout egg cache. If a buildout, which uses this cache, only knows about setuptools (as there's no distribute depencency in that buildout), you'll get the extra "hey, I already loaded this" UserWarnings. But, and that's the mostly-good news, these warnings only occur if you have a global setuptools and haven't installed distribute globally yet. In that case, somehow there's a fallback to the global setuptools which omits those warnings. IF warnings THEN install it also globally, basically. And, from what I see, a global install works just fine with a buildout that doesn't use the new bootstrap. Provided the setuptools in the egg cache has been patch already by some other buildout :-) Reinout -- Reinout van Rees - reinout@vanrees.org - http://reinout.vanrees.org Software developer at http://www.thehealthagency.com "Military engineers build missiles. Civil engineers build targets"
On 2009-10-09, Chris Withers <chris@simplistix.co.uk> wrote:
Reinout van Rees wrote:
I'm still not 100% sure whether it is safe to put "distribute" in the install_requires list of a package right now, however.
As with setuptools, why do you think you need to?
Namespace packages. You get warnings "hey, no setuptools dependency" once you use namespaces. Note that if I depend on distribute, I also get warnings about not having a setuptools depencency sometimes... :-) Reinout -- Reinout van Rees - reinout@vanrees.org - http://reinout.vanrees.org Software developer at http://www.thehealthagency.com "Military engineers build missiles. Civil engineers build targets"
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Reinout van Rees wrote:
On 2009-10-09, Chris Withers <chris@simplistix.co.uk> wrote:
Reinout van Rees wrote:
I'm still not 100% sure whether it is safe to put "distribute" in the install_requires list of a package right now, however. As with setuptools, why do you think you need to?
Namespace packages. You get warnings "hey, no setuptools dependency" once you use namespaces.
That is a buildout bug: whining about the lack of depenedency on the only package which makes dependencies meaningful is silly. No package should *ever* need to declare that it depends on setuptools.
Note that if I depend on distribute, I also get warnings about not having a setuptools depencency sometimes... :-)
Likewise. 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.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkrUuSgACgkQ+gerLs4ltQ7lewCZAS/MML7cmnzEnK1M6gbSSQHS lrQAn2KDOhsfT8Wtj83DW9G4WTOVXoS2 =VxBP -----END PGP SIGNATURE-----
On Tue, Oct 13, 2009 at 1:30 PM, Tres Seaver <tseaver@palladion.com> wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Reinout van Rees wrote:
On 2009-10-09, Chris Withers <chris@simplistix.co.uk> wrote:
Reinout van Rees wrote:
I'm still not 100% sure whether it is safe to put "distribute" in the install_requires list of a package right now, however. As with setuptools, why do you think you need to?
Namespace packages. You get warnings "hey, no setuptools dependency" once you use namespaces.
That is a buildout bug: whining about the lack of depenedency on the only package which makes dependencies meaningful is silly. No package should *ever* need to declare that it depends on setuptools.
I disagree. Dependencies only matter for installation. Lots of packages that are installed with setuptools don't need setuptools in their path to run. If a package imports setuptools, it should declare it as a dependency. The distribute fork and masquerade of setuptools makes this more complicated than it should be. Really the run-time code needed to support namespace packages should be split out into a separate package and eventually added to the standard library. Jim -- Jim Fulton
On 2009-10-13, Jim Fulton <jim@zope.com> wrote: [snip] As I reported a problem with the distribute/buildout combination earlier: The original problems I reported (and some others that I found) will all be solved in the upcoming 0.6.5 release! I worked with tarek today and yesterday to find (mainly me) and fix (mainly Tarek) small bugs. It works surprisingly elegant now. - You can include distribute safely in a dependency provided it is 0.6.5 or better. Also in buildouts that don't have a new bootstrap. - A shared eggs directory is no problem. The setuptools egg stays unmolested and coexists happily. - A new bootstrap is available that elegantly makes sure bin/buildout uses only distribute. This in turn ensures that no setuptools egg will show up anywhere else in any of the binaries. So... later tonight or tomorrow there can be rejoicing in buildout land. At least, that's what my automated buildbot tests say :-) Reinout -- Reinout van Rees - reinout@vanrees.org - http://reinout.vanrees.org Software developer at http://www.thehealthagency.com "Military engineers build missiles. Civil engineers build targets"
Reinout van Rees wrote:
- Do my libraries have to list a dependency on distribute or on setuptools? Everything zopish has a 'setuptools >= 0.6c9' in it.
They shouldn't, unless you only require setuptools after your package is installed and don't use it in your setup.py, which seems unlikely. If you need it in your setup.py, what's the point of specifying it? You would have had to use it by the time you specify the requirement!
- Do I need to change buildout's bootstrap already? Doing that tries to change my global setuptools,
It shouldn't. The normal buildout bootstrap.py doesn't... Chris
On Fri, Oct 9, 2009 at 1:07 PM, Chris Withers <chris@simplistix.co.uk> wrote:
Reinout van Rees wrote:
- Do my libraries have to list a dependency on distribute or on setuptools? Everything zopish has a 'setuptools >= 0.6c9' in it.
They shouldn't, unless you only require setuptools after your package is installed and don't use it in your setup.py, which seems unlikely.
If you need it in your setup.py, what's the point of specifying it? You would have had to use it by the time you specify the requirement!
I assume most packages Reinout uses (like all zope.* packages) use namespace packages. So they actually do depend during runtime on the pkg_resources module, which happens to be available from either the distribute or setuptools distribution. So one of them should be specified in install_requires. Hanno
On Fri, Oct 9, 2009 at 7:57 AM, Hanno Schlichting <hanno@hannosch.eu> wrote:
On Fri, Oct 9, 2009 at 1:07 PM, Chris Withers <chris@simplistix.co.uk> wrote:
Reinout van Rees wrote:
- Do my libraries have to list a dependency on distribute or on setuptools? Everything zopish has a 'setuptools >= 0.6c9' in it.
They shouldn't, unless you only require setuptools after your package is installed and don't use it in your setup.py, which seems unlikely.
If you need it in your setup.py, what's the point of specifying it? You would have had to use it by the time you specify the requirement!
I assume most packages Reinout uses (like all zope.* packages) use namespace packages. So they actually do depend during runtime on the pkg_resources module, which happens to be available from either the distribute or setuptools distribution. So one of them should be specified in install_requires.
This functionality should be factored out and merged with pkgutil in the standard library. Jim -- Jim Fulton
On Fri, Oct 9, 2009 at 3:14 PM, Jim Fulton <jim@zope.com> wrote:
On Fri, Oct 9, 2009 at 7:57 AM, Hanno Schlichting <hanno@hannosch.eu> wrote:
On Fri, Oct 9, 2009 at 1:07 PM, Chris Withers <chris@simplistix.co.uk> wrote: I assume most packages Reinout uses (like all zope.* packages) use namespace packages. So they actually do depend during runtime on the pkg_resources module, which happens to be available from either the distribute or setuptools distribution. So one of them should be specified in install_requires.
This functionality should be factored out and merged with pkgutil in the standard library.
Sure. That's what http://www.python.org/dev/peps/pep-0382 is about. But both Python 2.7 and 3.2 are a bit into the future, so it doesn't help with the current question. Hanno
Hanno Schlichting wrote:
I assume most packages Reinout uses (like all zope.* packages) use namespace packages. So they actually do depend during runtime on the pkg_resources module, which happens to be available from either the distribute or setuptools distribution. So one of them should be specified in install_requires.
You're missing my point. If you're using buildout, you automatically have setuptools available. If you're using easy_install, you automatically have setuptools available. So, the only case we can even consider is when you're installing a setuptools-based package with: python setup.py install In this case, which I suspect is extremely rare anyway, you'll need to have setuptools installed already. So, in *any* of these cases, specifying setuptools as a requirement seems like a total waste of time... Now, what case have I missed? ;-) Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk
On Fri, Oct 09, 2009 at 03:28:57PM +0100, Chris Withers wrote:
In this case, which I suspect is extremely rare anyway, you'll need to have setuptools installed already.
So, in *any* of these cases, specifying setuptools as a requirement seems like a total waste of time...
Now, what case have I missed? ;-)
It's nice for people creating system packages when you specify all of the packages that your runtime depends on in setup.py. That allows system packagers to read setup.py and be able to create the complete list of runtime dependencies for their packaging metadata. Several times I've been asked for help debugging why a python package fails to work for a few people only to discover that the package used entry-points or another setuptools runtime feature but only required it for buildtime. Note, however, that overspeciying the *versions* you need has the opposite effect :-) -Toshio
Toshio Kuratomi wrote:
On Fri, Oct 09, 2009 at 03:28:57PM +0100, Chris Withers wrote:
In this case, which I suspect is extremely rare anyway, you'll need to have setuptools installed already.
So, in *any* of these cases, specifying setuptools as a requirement seems like a total waste of time...
Now, what case have I missed? ;-)
It's nice for people creating system packages when you specify all of the packages that your runtime depends on in setup.py.
...except that it causes problems that are a bit more serious than "nice to have" because of the ridiculous situation we're in with setuptools and distribute... Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk
On Fri, Oct 09, 2009 at 04:04:06PM +0100, Chris Withers wrote:
Toshio Kuratomi wrote:
On Fri, Oct 09, 2009 at 03:28:57PM +0100, Chris Withers wrote:
In this case, which I suspect is extremely rare anyway, you'll need to have setuptools installed already.
So, in *any* of these cases, specifying setuptools as a requirement seems like a total waste of time...
Now, what case have I missed? ;-)
It's nice for people creating system packages when you specify all of the packages that your runtime depends on in setup.py.
...except that it causes problems that are a bit more serious than "nice to have" because of the ridiculous situation we're in with setuptools and distribute...
What's the issue precisely? Once distribute is on the system, setuptools is provided by distribute so there's no problem there, correct? Is it that the installers don't know that there's more than one package providing the setuptools API? That sounds like pypi and easy_install aren't powerful enough to recognize that an API can be provided by multiple modules. If you actually want to have a full-blown package manager you'll need to fix that but at the same time I'd warn that having a full-blown package manager means having to deal with a lot of corner cases like this. -Toshio
Toshio Kuratomi wrote:
On Fri, Oct 09, 2009 at 04:04:06PM +0100, Chris Withers wrote:
Toshio Kuratomi wrote:
On Fri, Oct 09, 2009 at 03:28:57PM +0100, Chris Withers wrote:
In this case, which I suspect is extremely rare anyway, you'll need to have setuptools installed already.
So, in *any* of these cases, specifying setuptools as a requirement seems like a total waste of time...
Now, what case have I missed? ;-)
It's nice for people creating system packages when you specify all of the packages that your runtime depends on in setup.py. ...except that it causes problems that are a bit more serious than "nice to have" because of the ridiculous situation we're in with setuptools and distribute...
What's the issue precisely? Once distribute is on the system, setuptools is provided by distribute so there's no problem there, correct?
The issue is that both the setuptools and distribute distributions provide a setuptools package. This apparently causes problems, rather unsurprisingly ;-) Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk
On Fri, Oct 09, 2009 at 05:13:16PM +0100, Chris Withers wrote:
Toshio Kuratomi wrote:
On Fri, Oct 09, 2009 at 04:04:06PM +0100, Chris Withers wrote:
Toshio Kuratomi wrote:
On Fri, Oct 09, 2009 at 03:28:57PM +0100, Chris Withers wrote:
In this case, which I suspect is extremely rare anyway, you'll need to have setuptools installed already.
So, in *any* of these cases, specifying setuptools as a requirement seems like a total waste of time...
Now, what case have I missed? ;-)
It's nice for people creating system packages when you specify all of the packages that your runtime depends on in setup.py. ...except that it causes problems that are a bit more serious than "nice to have" because of the ridiculous situation we're in with setuptools and distribute...
What's the issue precisely? Once distribute is on the system, setuptools is provided by distribute so there's no problem there, correct?
The issue is that both the setuptools and distribute distributions provide a setuptools package. This apparently causes problems, rather unsurprisingly ;-)
True... but because of that people are able to specify setuptools in setup.py and it will work with either distribute or setuptools. Is what you're getting at that if people didn't specify setuptools in setup.py, distribute-0.6 could install without using the setuptools name? I don't think that works since you still need to take over the setuptools module directory so import works inside the code and the setuptools egg-info so things like plugin modules belonging to setuptools work. -Toshio
Toshio Kuratomi wrote:
True... but because of that people are able to specify setuptools in setup.py and it will work with either distribute or setuptools.
If you mean in the "install_requires" or "setup_requires" parameters to setuptools setup method, then I'm yet to see a use case where this is required...
you're getting at that if people didn't specify setuptools in setup.py, distribute-0.6 could install without using the setuptools name?
Without faking the setuptools distribution, yes.
I don't think that works since you still need to take over the setuptools module
package != module != distribution. setuptools and distribute are both distributions that provide a setuptools package. However, requirements are specified in terms of distributions, which is why people specifying setuptools as a requirement causes problems. As I've said several times now, I just can't see any point in doing that... will someone please enlighten me as to why people feel the need to specify "setuptools" in "install_requires" or "setup_requires" when the code that parses those requirements can't execute unless a package called setuptools is present already? Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hanno Schlichting wrote:
On Fri, Oct 9, 2009 at 1:07 PM, Chris Withers <chris@simplistix.co.uk> wrote:
Reinout van Rees wrote:
- Do my libraries have to list a dependency on distribute or on setuptools? Everything zopish has a 'setuptools >= 0.6c9' in it. They shouldn't, unless you only require setuptools after your package is installed and don't use it in your setup.py, which seems unlikely.
If you need it in your setup.py, what's the point of specifying it? You would have had to use it by the time you specify the requirement!
I assume most packages Reinout uses (like all zope.* packages) use namespace packages. So they actually do depend during runtime on the pkg_resources module, which happens to be available from either the distribute or setuptools distribution. So one of them should be specified in install_requires.
Why? Nobody will check / enforce / understand what 'install_requires' even means except setuptools / distribute. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkrUuWwACgkQ+gerLs4ltQ5G8wCgjfmDazDum+ClDnxDtw+nxImD W4AAoKElE+Uelm3yL30Kdjj/6YFpL+4C =KIbC -----END PGP SIGNATURE-----
On Tue, Oct 13, 2009 at 7:31 PM, Tres Seaver <tseaver@palladion.com> wrote:
Why? Nobody will check / enforce / understand what 'install_requires' even means except setuptools / distribute.
To quote Toshio Kuratomi:
It's nice for people creating system packages when you specify all of the packages that your runtime depends on in setup.py.
So apparently there are others who read and value this information. Hanno
Hanno Schlichting wrote:
On Tue, Oct 13, 2009 at 7:31 PM, Tres Seaver <tseaver@palladion.com> wrote:
Why? Nobody will check / enforce / understand what 'install_requires' even means except setuptools / distribute.
To quote Toshio Kuratomi:
It's nice for people creating system packages when you specify all of the packages that your runtime depends on in setup.py.
So apparently there are others who read and value this information.
I'd put money on there being no packaging system that parses requirements sections out of a setup.py other that setuptools/distribute... Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk
Chris Withers a écrit :
Hanno Schlichting wrote:
On Tue, Oct 13, 2009 at 7:31 PM, Tres Seaver <tseaver@palladion.com> wrote:
Why? Nobody will check / enforce / understand what 'install_requires' even means except setuptools / distribute.
To quote Toshio Kuratomi:
It's nice for people creating system packages when you specify all of the packages that your runtime depends on in setup.py.
So apparently there are others who read and value this information.
I'd put money on there being no packaging system that parses requirements sections out of a setup.py other that setuptools/distribute...
buildout, zc.recipe.egg and others recipes flavors do.
Chris
-- Cordialement, KiOrKY GPG Key FingerPrint: 0x1A1194B7681112AF
2009/10/20 kiorky <kiorky@cryptelium.net>:
buildout, zc.recipe.egg and others recipes flavors do.
But they use setuptools to do so, I hope? -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64
For minitage.recipe.*, yes it uses setuptools API. They also redo on the fly the python sdist dance in some case and reload the distribution using also setuptools API. And in the "patch" use case [1], they also patch the PKG-INFO file with a generated version info and use setuptools API to reload the distribution. For what i know of others API, they don't mess directly with setup.py either. [1] - http://pypi.python.org/pypi/minitage.recipe.egg#patches Lennart Regebro a écrit :
2009/10/20 kiorky <kiorky@cryptelium.net>:
buildout, zc.recipe.egg and others recipes flavors do.
But they use setuptools to do so, I hope?
-- Cordialement, KiOrKY GPG Key FingerPrint: 0x1A1194B7681112AF
On Tue, Oct 20, 2009 at 7:05 AM, kiorky <kiorky@cryptelium.net> wrote:
buildout, zc.recipe.egg and others recipes flavors do.
These tools don't parse setup.py; they execute setup.py in a constrained context (possibly a separate process; don't recall offhand) in order to collect the metadata. Parsing the setup.py would be insane. -Fred -- Fred L. Drake, Jr. <fdrake at gmail.com> "Chaos is the score upon which reality is written." --Henry Miller
Fred Drake wrote:
Parsing the setup.py would be insane.
As is specifying the setuptools distribution as a requirement when you're already using it... Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk
On Tue, Oct 20, 2009 at 9:39 AM, Chris Withers <chris@simplistix.co.uk> wrote:
As is specifying the setuptools distribution as a requirement when you're already using it...
I don't use setuptools at runtime unless something requires it. Having it available at install time and run time are two different things, and should remain so. -Fred -- Fred L. Drake, Jr. <fdrake at gmail.com> "Chaos is the score upon which reality is written." --Henry Miller
Fred Drake wrote:
On Tue, Oct 20, 2009 at 9:39 AM, Chris Withers <chris@simplistix.co.uk> wrote:
As is specifying the setuptools distribution as a requirement when you're already using it...
I don't use setuptools at runtime unless something requires it.
Having it available at install time and run time are two different things, and should remain so.
All I'm saying is that packages shouldn't express a dependency on setuptools if setuptools is required even before that expression can be parsed. I'm not talking about install or run time... Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk
On Tue, Oct 20, 2009 at 02:48:58PM +0100, Chris Withers wrote:
Fred Drake wrote:
On Tue, Oct 20, 2009 at 9:39 AM, Chris Withers <chris@simplistix.co.uk> wrote:
As is specifying the setuptools distribution as a requirement when you're already using it...
I don't use setuptools at runtime unless something requires it.
Having it available at install time and run time are two different things, and should remain so.
All I'm saying is that packages shouldn't express a dependency on setuptools if setuptools is required even before that expression can be parsed.
I'm not talking about install or run time...
Are you then talking about build time? -Toshio
Toshio Kuratomi wrote:
On Tue, Oct 20, 2009 at 02:48:58PM +0100, Chris Withers wrote:
On Tue, Oct 20, 2009 at 9:39 AM, Chris Withers <chris@simplistix.co.uk> wrote:
As is specifying the setuptools distribution as a requirement when you're already using it... I don't use setuptools at runtime unless something requires it.
Having it available at install time and run time are two different things, and should remain so. All I'm saying is that packages shouldn't express a dependency on setuptools if setuptools is required even before that expression can be
Fred Drake wrote: parsed.
I'm not talking about install or run time...
Are you then talking about build time?
I'm talking about *at all*. Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk
On Tue, Oct 27, 2009 at 11:35 AM, Chris Withers <chris@simplistix.co.uk> wrote:
I'm talking about *at all*.
If I don't include setuptools in install_requires, then I've no business expecting it to be available at runtime. Since our current approach in the Zope community is to use pkg_resources to support namespace packages, and we get that via setuptools, it makes sense to specify that my packages require setuptools. It's just unfortunate that we're not able to get what we need from the standard library for all interesting versions of Python. -Fred -- Fred L. Drake, Jr. <fdrake at gmail.com> "Chaos is the score upon which reality is written." --Henry Miller
Fred Drake wrote:
On Tue, Oct 27, 2009 at 11:35 AM, Chris Withers <chris@simplistix.co.uk> wrote:
I'm talking about *at all*.
If I don't include setuptools in install_requires, then I've no business expecting it to be available at runtime.
You're ignoring the fact that for the information in install_requires to even be parsed, you need to have setuptools present. I'll say it again: it seems pointless specifying a requirement that has to be met before any requirement specifications can even be processed... Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk
On Tue, Oct 27, 2009 at 12:26 PM, Chris Withers <chris@simplistix.co.uk> wrote:
You're ignoring the fact that for the information in install_requires to even be parsed, you need to have setuptools present.
install_requires is processed at install time. At that time, clearly, setuptools/distribute is present. That's not necessarily the case at run time. I see no reason to expect that having setuptools or distribute on sys.path at install time would cause it to necessarily be on the path at run time if my package doesn't provide information that it's needed at run time.
I'll say it again: it seems pointless specifying a requirement that has to be met before any requirement specifications can even be processed...
It doesn't sound to me like you've used buildout nearly as much as easy install. -Fred -- Fred L. Drake, Jr. <fdrake at gmail.com> "Chaos is the score upon which reality is written." --Henry Miller
Fred Drake wrote:
On Tue, Oct 27, 2009 at 12:26 PM, Chris Withers <chris@simplistix.co.uk> wrote:
You're ignoring the fact that for the information in install_requires to even be parsed, you need to have setuptools present.
install_requires is processed at install time. At that time, clearly, setuptools/distribute is present.
By "is", I'm sure you mean "needs to be". Specifying setuptools in install_requires is pointless chicken-and-egg'ing. But maybe I mean "setup_requires" thanks to setuptools "interesting" parameter naming ;-)
That's not necessarily the case at run time. I see no reason to expect that having setuptools or distribute on sys.path at install time would cause it to necessarily be on the path at run time if my package doesn't provide information that it's needed at run time.
Fair point.
I'll say it again: it seems pointless specifying a requirement that has to be met before any requirement specifications can even be processed...
It doesn't sound to me like you've used buildout nearly as much as easy install.
Er? I *only* use buildout, however, I think I may have exempted myself by avoiding namespace packages until PEP 382 is done, dusted and in a python release. Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk
On Wed, Oct 28, 2009 at 10:09 AM, Chris Withers <chris@simplistix.co.uk> wrote:
By "is", I'm sure you mean "needs to be". Specifying setuptools in install_requires is pointless chicken-and-egg'ing. But maybe I mean "setup_requires" thanks to setuptools "interesting" parameter naming ;-)
You just might. install_requires is for what's needed at run time, which is what most of us mean when we refer to install_requires by name.
Er? I *only* use buildout, however, I think I may have exempted myself by avoiding namespace packages until PEP 382 is done, dusted and in a python release.
Your use of buildout is obvious in many contexts, but do realize why I (and likely others) wondered at your insistence that mentioning setuptools there was meaningless. Clarifying this hasn't been cheap (though valuable, IMO). -Fred -- Fred L. Drake, Jr. <fdrake at gmail.com> "Chaos is the score upon which reality is written." --Henry Miller
At 01:31 PM 10/13/2009 -0400, Tres Seaver wrote:
Why?
Because the user might have, say, setuptools 0.6c8, and the package relies on a bugfix in 0.6c9. Also, at some point, there will be an 0.7a1, with new features that some people might actually want to use. (Some projects also actually use setuptools or easy_install at runtime, not just pkg_resources; e.g. buildout, pip, etc.)
Nobody will check / enforce / understand what 'install_requires' even means except setuptools / distribute.
Nobody except system packagers, who would otherwise have to troll the source for pkg_resources imports and such. (Even then, a project could declare entry points in its setup.py that will get called by some other project, without ever directly using a pkg_resources or setuptools API.)
participants (11)
-
Chris Withers -
Fred Drake -
Hanno Schlichting -
Jim Fulton -
kiorky -
Lennart Regebro -
P.J. Eby -
Reinout van Rees -
Tarek Ziadé -
Toshio Kuratomi -
Tres Seaver