Re: [Distutils] Package install failures in 2.6.3 - setuptools vs Distribute
2009/10/7 Tres Seaver tsea...@palladion.com: The fact that the bugfix (to distutils) was committed by folks who are *alos* pusing a fork to setuptools is what raises the eyebrows here. Eh... why? Tarek has become the lead for Python packaging programs and is trying hard to fix the sad state of Python packaging. It's not particularily surprising that he (or otehrs involved in Python packaging) would be involved in more than one package. Note that I am *not* suggesting that anyone acted in bad faith; but the appearance of impropriety can be present where no actual impropriety exists. The only cure is for the conflicted parties to take extreme measures to avoid appearing to act improperly. ... There are those postig on this thread that the distutils breakage is a good thing for Distribute, because it *forces* folks to switch: I call that a solid hint, myself. I'm sorry, but I read this as you implying that somebody could think Tarek, me and other Distribute people is involved in some sort of Python packaging conspiracy. I can't take that seriously, so I really hope that you mean something else, because that idea is just laughable. There is no appearance of impropriety. There is no conflicted party. There is no conflict. You can't read anything as being good for Distribute, because there is no good for Distribute. Distribute does not benefit from people using it. People benefit from using Distribute. I suspect that you see some conflict or competition between Distribute and setuptools when there is none. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64 ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
[Distutils] Distutils 0.6.4 this week
Hello, We are going to ship Distribute 0.6.4 by the end of this week with a few more bugs fixed, whereas they were listed in Setuptools tracker (http://bitbucket.org/tarek/distribute/wiki/bug_listing) whereas they were added directly in our tracker. If you had any issue you want to see fixed in this release, please speak up. If you want to help, you can install and play with the nightly build of 0.6.4 by running: http://nightly.ziade.org/distribute_setup_dev.py Last, a new wiki page has been added where we are giving more details on the roadmap for 0.6.x and 0.7.x : http://bitbucket.org/tarek/distribute/wiki/roadmap Regards Tarek -- Tarek Ziadé | http://ziade.org | オープンソースはすごい! | 开源传万世，因有你参与 ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Distutils 0.6.4 this week
On 2009-10-07, Tarek Ziadé ziade.ta...@gmail.com wrote: We are going to ship Distribute 0.6.4 by the end of this week with a few more bugs fixed, whereas they were listed in Setuptools tracker (http://bitbucket.org/tarek/distribute/wiki/bug_listing) whereas they were added directly in our tracker. If you had any issue you want to see fixed in this release, please speak up. http://bitbucket.org/tarek/distribute/issue/23/warning-about-module-was-already-imported The Module pkg_resources was already imported from-like warnings when running something inside buildout are irritating. They also break a script I have that calls python setup.py --name on several packages to grab their name. Normally you get the name, now you get several lines of warnings, followed by the name. Otherwise I have to go back to a regex :-) Reinout -- Reinout van Rees - rein...@vanrees.org - http://reinout.vanrees.org Software developer at http://www.thehealthagency.com Military engineers build missiles. Civil engineers build targets ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
[Distutils] 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 - rein...@vanrees.org - http://reinout.vanrees.org Software developer at http://www.thehealthagency.com Military engineers build missiles. Civil engineers build targets ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Package install failures in 2.6.3 - setuptools vs Distribute
On 07.10.2009, at 01:08, Sridhar Ratnakumar wrote: On Tue, 06 Oct 2009 10:25:04 -0700, kiorky kio...@cryptelium.net wrote: The fork was started by Philip Jenvey at http://bitbucket.org/pjenvey/virtualenv-distribute/ and this version by Florian Schulze lives at http://bitbucket.org/fschulze/virtualenv-distribute/ [1] - http://pypi.python.org/pypi/virtualenv-distribute/ Just a suggestion: could someone make that /fschulze/virtualenv- distribute site (the current 'home page' of the project) link to the launchpad bug tracker? Up until now, I was not able to track down an issue tracker for this fork .. until you posted the PyPI link. This way one - who stumbled upon the bitbucket site - does not have to pull the source tree and look in docs/index.rst in order to get the URL to the bug tracker. (I had a bug to report a couple of days). Ah, found the setting at bitbucket to enable the issue tracker, thanks kiorky to make me look deeper. http://bitbucket.org/fschulze/virtualenv-distribute/issues/?status=newstatus=open Regards, Florian Schulze ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] distribute and buildout: best practices?
On Wed, Oct 7, 2009 at 1:23 PM, Reinout van Rees rein...@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 | オープンソースはすごい! | 开源传万世，因有你参与 ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] distribute and buildout: best practices?
On 2009-10-07, Tarek Ziadé ziade.ta...@gmail.com wrote: On Wed, Oct 7, 2009 at 1:23 PM, Reinout van Rees rein...@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 - rein...@vanrees.org - http://reinout.vanrees.org Software developer at http://www.thehealthagency.com Military engineers build missiles. Civil engineers build targets ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] distribute and buildout: best practices?
On 2009-10-07, Tarek Ziadé ziade.ta...@gmail.com wrote: On Wed, Oct 7, 2009 at 2:32 PM, Reinout van Rees rein...@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 - rein...@vanrees.org - http://reinout.vanrees.org Software developer at http://www.thehealthagency.com Military engineers build missiles. Civil engineers build targets ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Package install failures in 2.6.3 - setuptools vs Distribute
On Oct 7, 2009, at 3:18 AM, Florian Schulze wrote: This way one - who stumbled upon the bitbucket site - does not have to pull the source tree and look in docs/index.rst in order to get the URL to the bug tracker. (I had a bug to report a couple of days). The launchpad bugtracker is for virtualenv, not this fork. Sadly I just realized bitbucket.org doesn't have an integrated issue tracker like github :( Uh...it's cleverly hidden under the Issues tab on the project page. S ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Package install failures in 2.6.3 - setuptools vs Distribute
On 07.10.2009, at 16:21, sstein...@gmail.com wrote: On Oct 7, 2009, at 3:18 AM, Florian Schulze wrote: This way one - who stumbled upon the bitbucket site - does not have to pull the source tree and look in docs/index.rst in order to get the URL to the bug tracker. (I had a bug to report a couple of days). The launchpad bugtracker is for virtualenv, not this fork. Sadly I just realized bitbucket.org doesn't have an integrated issue tracker like github :( Uh...it's cleverly hidden under the Issues tab on the project page. I had to enable it in the cleverly hidden Admin tab first. Regards, Florian Schulze ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Package install failures in 2.6.3 - setuptools vs Distribute
On Oct 7, 2009, at 10:51 AM, Florian Schulze wrote: On 07.10.2009, at 16:21, sstein...@gmail.com wrote: On Oct 7, 2009, at 3:18 AM, Florian Schulze wrote: This way one - who stumbled upon the bitbucket site - does not have to pull the source tree and look in docs/index.rst in order to get the URL to the bug tracker. (I had a bug to report a couple of days). The launchpad bugtracker is for virtualenv, not this fork. Sadly I just realized bitbucket.org doesn't have an integrated issue tracker like github :( Uh...it's cleverly hidden under the Issues tab on the project page. I had to enable it in the cleverly hidden Admin tab first. Told'ya it was cleverly hidden. ;-) I forgot about that; I think I had exactly the same Where the heck's the issue tracker? moment when I started my first repository. Why it's not enabled by default is one of the deep mysteries... Glad you found it! S ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
