Mailman 3 October 2009 - Distutils-SIG

Distribute 0.6.5 coming up
by Tarek Ziadé 15 Oct '09

15 Oct '09

Hey, Reinout and I have worked on bugs related to zc.buildout support, and it seems that now everything works fine. Thanks for those who try it on their side ! So we will be shipping a 0.6.5 probably friday for that, and postpone all the other issues for 0.6.6, except a few ones that are easy to tackle now. This version will also contaon the code that lakes sure we don't step on any Setuptools 0.7.x toes. If you have one issue you want to see fixed in 0.6.5, speak up. buildouters, if you want to try the latest dev version you can grab : http://python-distribute.org/bootstrap_dev.py Once 0.6.6 is proven to be working fine with zc.buildout, I'll change on zc.buildout side the bootstrap.py script as suggested, by adding a "--distribute" option so people can choose the tool they want to use. Thanks Tarek -- Tarek Ziadé | http://ziade.org | オープンソースはすごい! | 开源传万世，因有你参与

2 1

Future namespace support
by Lennart Regebro 15 Oct '09

15 Oct '09

2009/10/14 kiorky <kiorky(a)cryptelium.net>: >> This may be quite current even if it's not a good habit to have circular >> dependencies between distributions. >> Imagine that. >> >> B(0.7) -> A(0.6). >> A(0.6) -> B(0.7). I don't think that's a problem, although I can't see why you would need it in this case. >> Can i have the same namespace "ns" shared between the twice distributions with >> both the setuptools namespaces implementation (A) and the pkg_util's one (B)? I don't see why not, they would work the same way. Possibly the global _namespace_packages dictionary needs to be shared by both setuptools and the new module, but that can easily be handled by importing it from setuptools if setuptools is installed. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64

3 17

Re: [Distutils] Future namespace support
by P.J. Eby 15 Oct '09

15 Oct '09

At 04:55 PM 10/14/2009 +0200, Lennart Regebro wrote: >2009/10/14 kiorky <kiorky(a)cryptelium.net>: > > That's not what said the PEP (IOW what i had understood of) > >Oh, you don't *use* it the same way, no, but I assumed that the >internal mechanisms would be similar. Maybe I was wrong. You can use as many namespace package mechanisms as you want, simultaneously, as long as they're not all being used for the same namespace package. Bear in mind that the true mechanism of nsp's is simply a module's __path__ object; pkgutil and pkg_resources simply provide utilities for setting the __path__ appropriately. With PEP 382, the utilities become unnecessary, except for backward compatibility, and if you want to do fixup of a __path__ when sys.path is changed. However, as long as each nsp is only registered with one such utility, there should be no conflicts.

3 3

Re: [Distutils] [buildout] RFC: buildout support for distribute
by P.J. Eby 13 Oct '09

13 Oct '09

At 10:27 PM 10/13/2009 +0200, Tarek Ziadé wrote: >On Tue, Oct 13, 2009 at 10:07 PM, P.J. Eby <pje(a)telecommunity.com> wrote: > >> Ok sure, makes sense. We will return 'distribute' only if 'setuptools' > >> is from the 0.6.x series > >> and below. > > > > Great. I assume that means you plan to incorporate any further bug fixes > > that land in 0.6c10 (or, gods forbid, c11) in the release where this change > > is made. > >Yes, as long as we are able to spot them in your commits / issue >trackers changes. > >The latest commit you've made in setuptools package is still cryptic >to us because >it fixes many things at once. Sorry about that, but it was pretty much the only way to get it done in a weekend, without the overheads of separate commit messages, doc changes, and backporting killing me. Those overheads were the main reason I wasn't making changes more often; I dreaded the amount of work involved. Also, as it happened, I was able to fix multiple problems with single changes this way. >We were able to backport the sandbox violation but that's it at this point. The __getstate__/__setstate__ stuff in pkg_resources is also sandbox support; it makes it possible to keep working_set changes by recursive builds from corrupting the parent build's working set. I also expect it to support a "reset pkg_resources" API in 0.7a1 -- a long-requested feature. > > For versions you don't support emulating, I strongly suggest > adding an error > > of some kind, since actually *installing* setuptools with Distribute still > > present on sys.path would cause a problem. > >It is still unclear to me where this exception has to be thrown >since some APIs >in WorkingSet can be used just to check things out. > >I am guessing WorkingSet.resolve and parse_requirements are enough, but that's >just from the zc.buildout use case. One thing you could possibly do is capture Distribution.insert_on(), which would allow you to detect that setuptools is about to be added to a working set. Still another is that you could install a distribute.pth that puts Distribute on the path first, since 'distribute.pth' is alphabetically before 'easy-install.pth' and 'setuptools.pth'. (I'm not suggesting these are complete or risk-free solutions, of course.)

1 0

Re: [Distutils] [buildout] RFC: buildout support for distribute
by P.J. Eby 13 Oct '09

13 Oct '09

At 09:53 PM 10/13/2009 +0200, Tarek Ziadé wrote: >2009/10/13 P.J. Eby <pje(a)telecommunity.com>: > > At 09:25 PM 10/13/2009 +0200, Tarek Ziadé wrote: > >> > >> Notice that the current trunk of Distribute is now changing any > >> 'setuptools' > >> requirement that is tiggered using "Requirement.parse" and "resolve" APIs > >> into > >> a 'distribute' one. > > > > Please note that this change will cause problems for people in the future, > > as new features are introduced in the 0.7a1 line. The earlier version of > > this hack, which only ignored requests for older versions of setuptools, > > would not have caused such a problem. > > > > I would suggest that Distribute should only silently ignore requests for > > versions of setuptools that it can explicitly emulate; other > requests should > > result in an error, so that a problem cannot pass silently. > > > > Otherwise, a package depending on new features in the 0.7 line > will silently > > fail when those features are not present in its operating environment. > >Ok sure, makes sense. We will return 'distribute' only if 'setuptools' >is from the 0.6.x series >and below. Great. I assume that means you plan to incorporate any further bug fixes that land in 0.6c10 (or, gods forbid, c11) in the release where this change is made. For versions you don't support emulating, I strongly suggest adding an error of some kind, since actually *installing* setuptools with Distribute still present on sys.path would cause a problem.

2 1

Re: [Distutils] [buildout] RFC: buildout support for distribute
by P.J. Eby 13 Oct '09

13 Oct '09

At 09:25 PM 10/13/2009 +0200, Tarek Ziadé wrote: >Notice that the current trunk of Distribute is now changing any 'setuptools' >requirement that is tiggered using "Requirement.parse" and "resolve" APIs into >a 'distribute' one. Please note that this change will cause problems for people in the future, as new features are introduced in the 0.7a1 line. The earlier version of this hack, which only ignored requests for older versions of setuptools, would not have caused such a problem. I would suggest that Distribute should only silently ignore requests for versions of setuptools that it can explicitly emulate; other requests should result in an error, so that a problem cannot pass silently. Otherwise, a package depending on new features in the 0.7 line will silently fail when those features are not present in its operating environment.

2 1

Re: [Distutils] distribute and buildout: best practices?
by P.J. Eby 13 Oct '09

13 Oct '09

At 02:51 PM 10/13/2009 -0400, Jim Fulton wrote: >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. Are you volunteering? ;-) Seriously, MvL's namespace package PEP (#382) already takes care of most everything that's needed. With it in place, the only advantage of setuptools' approach is the ability to add more items to a package __path__ after it's already imported. (i.e., the fixup feature.) I heartily approve of that PEP, in case it's not obvious. I'd love to see it in Python 2.7, and will happily add support for it in setuptools 0.7.

2 1

[buildout] RFC: buildout support for distribute
by Jim Fulton 13 Oct '09

13 Oct '09

I plan to add explicit buildout support for distribute. Here's a sketch. Basically it boils down to satisfying requirements for setuptools with distribute whenever distribute is in buildout's working set. So, when installing a package that requires setuptools, it will convert that requirement to a requirement for distribute. There will be 2 separate bootstrap scripts, one that uses distribute and one that uses setuptools. There will also be a buildout configuration option that will allow a buildout configuration author to fix which is used. Probably: use-distribute = true This will only serve as a check that the right bootstrap was used. Comments? Jim -- Jim Fulton

3 4

dev versions
by Ian Bicking 13 Oct '09

13 Oct '09

So after creating, say, version 0.3.1, I always mark a package as 0.3.2dev. But this is annoying, you might never create a version 0.3.2 (e.g., 0.4 might be the next level). So, it would be better to use something like 0.3.1~dev. What is considered best practice for this? Ideally something that works with both Setuptools and the upcoming Distribute version spec. -- Ian Bicking | http://blog.ianbicking.org | http://topplabs.org/civichacker

14 17

Setuptools 0.6c10 release imminent; please test
by P.J. Eby 13 Oct '09

13 Oct '09

I've just updated the setuptools trunk and branch with a large number of bug fixes, preparing to release 0.6c10. These fixes include fixes for all the setuptools bugs currently marked "in-progress" or "testing" on the setuptools bug tracker as of this moment, and I'd like your help in ensuring that the new version is ready for release. Major updates and fixes include: * Fix for Vista UAC errors running easy_install.exe or other "installer-looking" executables * Fix for errors launching 64-bit Windows Python * Fix for the Python 2.6.3 build_ext API change * Support for the most recent Sourceforge download link insanity * Support for SVN 1.6 * Stop crashing on certain types of HTTP error * Stop re-trying URLs that already failed retrieval once * Fixes for various dependency management problems such as looping builds, re-downloading packages already present on sys.path (but not in a registered "site" directory), and randomly preferring local -f packages over local installed packages * Prevent lots of spurious "already imported from another path" warnings (e.g. when pkg_resources is imported late) * Ensure C libraries (as opposed to extensions) are also built when doing bdist_egg * Fixed running the "test" command under Python 2.6+ (0.7a1 trunk only) Other changes: * Misc. documentation fixes * Improved Jython support * Fewer warnings under Python 2.6+ * Warn when 'packages' uses paths instead of package names (because it causes other problems, like spurious "already imported" warnings) * Stop using /usr/bin/sw_vers on Mac OS (replaced w/'platform' module calls) You can install the updated version using easy_install (or pip!), asking for setuptools==dev (for the 0.7a1 trunk) or setuptools==dev06 (for the 0.6c10 development branch). But before you do that, be sure to uninstall Distribute completely. In particular, please note that these changes are NOT a merge from Distribute; upon review, many of the tracker-submitted patches used as a basis for forking were incorrect, incomplete, introduced new bugs, or were not addressing the root causes. (E.g., one of the changes I made fixes three superficially unrelated issues in the setuptools bug tracker.) Even if some of the change descriptions are the same in Distribute, many of the fixes are implemented quite differently.

11 14