Mailman 3 October 2009 - Distutils-SIG

[RFC] PEP 345 and PEP 386 updates
by Tarek Ziadé Oct. 27, 2009

Oct. 27, 2009

Hi, PEP 345 is the PEP for the new metadata format, replacing PEP 314. I have upgraded it, using Tres's work from last year, and the next step is to add the context marker presented in PEP 390. I have also updated PEP 386 to link it to PEP 345. = PEP 345 : Summary of Differences From PEP 314 = * Metadata-Version is now 1.2. * Added fields: - Maintainer - Maintainer-email - Requires-Python - Requires-External - Requires-Dist - Provides-Dist - Obsoletes-Dist * Deprecated fields: - Requires (in favor of Requires-Dist) - Provides (in favor of Provides-Dist) - Obsoletes (in favor of Obsoletes-Dist) Please comment! Tarek

10 29

Distribute 0.6.7 this week
by Tarek Ziadé Oct. 27, 2009

Oct. 27, 2009

Hello We are going to release 0.6.7 this week. Among some new bugs fixes, we want to provide a specific change that will allow virtualenv to be released with an option to use Distribute instead of Setuptools, like zc.buildout. $ virtualenv --distribute ENV If you want to see another bug fixed in this release, speak up ! (http://bitbucket.org/tarek/distribute/issues) Regards Tarek -- Tarek Ziadé | http://ziade.org | オープンソースはすごい! | 开源传万世，因有你参与

2 4

[buildout] A few pending issues
by Kai Lautaportti Oct. 25, 2009

Oct. 25, 2009

Hi, I've reported a few issues on the zc.buildout bug tracker, mainly https://bugs.launchpad.net/zc.buildout/+bug/435837 https://bugs.launchpad.net/zc.buildout/+bug/439387 with proposed patches that I would be interested in having included in the next release of zc.buildout. The #439387 issue is trivial, but I am not sure if the patch I proposed for #435837 is appropriate and would appreciate some additional reviewing and feedback. I would also like to get https://bugs.launchpad.net/zc.buildout/+bug/113085 fixed to make zc.buildout interact better with buildbot. Has anyone looked into this lately? In any case, I would be willing to spend time on these issues during the upcoming Plone conference sprint to make sure the fixes get merged into trunk. Is there anything special I can do to make this happen? Cheers, Kai -- Kai Lautaportti

3 4

Distribute sprint #1 wrapup
by Tarek Ziadé Oct. 24, 2009

Oct. 24, 2009

As promised, here's a quick wrapup of the work started during the first sprint, on Distribute 0.7 Thanks to all the people that have participated (we were 6 or 7 IIRC) If you have sprinted and see a mistake or something missing is the wrapup, please complete it; = The fate of 0.6 code = First of all, we've discussed what is happening to the 0.6 code and we've decided that it was better to keep it under the pillow as a reference code, and code everything from scratch. The only code that is going to be recycled is some parts of pkg_resources. = 0.7 philosophy = Distribute 0.7 will be a good Distutils citizen and wants to be its incubator. It will implement Distutils commands, without changing Distutils behavior as it is doing now. Another important point is that the Distribute development will be driven by the PEP work that is going on and drop most other concepts of Setuptools: - PEP 376 : a *single* installation standard - PEP 345 : Requires, Obsoletes, etc, fields - PEP 390 : platform-dependant markers for the metadata - PEP 382 : namespace packages - PEP 386 : a new version scheme Distribute will implement those PEPs by gathering all the prototypes that have been created in the past months and when possible, will try to push them in Distutils. The biggest drops we are making are: - the egg formats are removed in favor of a unique PEP 376 standard. - easy_install is removed, and Distribute will cooperate with the pip project What's unclear right now is what will be pushed in Distutils by the time Python 2.7 and 3.3 are out. = what was started during the sprint = We started to write Distutils commands: - develop command: * Created a skeleton command for develop * Waiting for work to complete on the install and build_egg_info commands before work can continue here. - build_egg_info command (in setuptools, it was called "egg_info", we've renamed it): * Rewrote this command using setuptools code as a model * Removed all SVN support code * Removed obsolete egg-info writers * Waiting on the manifest generation feature to finish this one * Will implement PEP 376 egg-info writers when possible - generate_manifest command. Not started yet, but will be used to generate the MANIFEST file, and provide a plugin system for VCS support. (not an implicit system like in Setuptools) - install command - building a PEP 376 compatible install command (by rewriting pkg_resources, using the PEP 376 prototype we have written some time ago) - distutils.extensions : lightweight entry points, based on the PEP 376 standard taken back from the "extensions" project - Currently working on testing strategy = next sprint = The next sprint will be next week-end, and will be announced here; Anyone can join ! Thanks Tarek -- Tarek Ziadé | http://ziade.org | オープンソースはすごい! | 开源传万世，因有你参与

3 6

Distribute support added in zc.buildout
by Tarek Ziadé Oct. 24, 2009

Oct. 24, 2009

Hey, I have added in zc.buildout trunk the Distribute support. The unified bootstrap now has a --distribute boolean option that allows you to switch if you want. its located here as usual : http://svn.zope.org/*checkout*/zc.buildout/trunk/bootstrap/bootstrap.py Please try it ! I will wait a few days to make sure everything works as expected then push a zc.buildout 1.4.2 release that includes this change Cheers Tarek

6 14

First attempt: close but no data files!
by Kaelin Colclasure Oct. 23, 2009

Oct. 23, 2009

Greetings, I am attempting my first Python contribution and have run into a speed bump getting a working setup.py using setuptools. Specifically, I cannot coax it to install my package data files into the site-packages directory. Here is a link to my project where my setup.py is available for browsing: <http://bitbucket.org/kaelin/cuttlefish/> Soooo close! TIA, -- Kaelin

3 9

zc.buildout and site-packages
by Martin Aspeli Oct. 23, 2009

Oct. 23, 2009

Hi, Is there a way (apart from putting buildout in a virtualenv with --no-site- packages) to tell buildout *not* to put site-packages as the first line in the mangled sys.path when it generates scripts? We have people doing horrid things to their global python, and we need the buildout to be safe and isolated in these environments. Martin

5 4

Preparing Distribute sprint #1 wrapup
by Tarek Ziadé Oct. 22, 2009

Oct. 22, 2009

Hey, Thanks to all sprinters, this was fun. Another sprint will be soon planned. I'd like to write a wrapup of the sprint we've done, so we can explain what's been done and what's next. If you were at that sprint and a "nominated" leader of one of the team, please add a summary of what has been done so far in your team, with links to the repositories when needed here : http://wiki.python.org/moin/Distutils/DistributeSprint (or a link to your blog if this has been done there) Thank you ! Tarek

1 0

Re: [Distutils] [Python-Dev] Distutils and Distribute roadmap (and some words on Virtualenv, Pip)
by Chris Withers Oct. 20, 2009

Oct. 20, 2009

Chris Withers wrote: > [following up on distutils-sig] > > Michael Foord wrote: >> Many Windows users would be quite happy if the standard mechanism for >> installing non-source distributions on Windows was via the wininst >> binaries. > > ...and many users may not be ;-) I know I'd be extremely unhappy if that > were the case as I routines use multiple versions of packages with > multiple versions of python on one machine... > >> I wonder if it is going to be possible to make this compatible with >> the upcoming distutils package management 'stuff' (querying for >> installed packages, uninstallation etc) since >> installation/uninstallation goes through the Windows system package >> management feature. I guess it would be eminently possible but >> require some reasonably high level Windows-fu to do. > > I wouldn't have a problem if integrating with the windows package > manager was an optional extra, but I think it's one of many types of > package management that need to be worried about, so might be easier to > get the others working and let anyone who wants anything beyond a > pure-python packaging system that works across platforms, regardless of > whether binary extensions are needed, do the work themselves... > > Chris > -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk

1 0

Setuptools 0.6c11 released
by P.J. Eby Oct. 20, 2009

Oct. 20, 2009

Oops! ----- Due to a couple of last-minute issues with the 0.6c10 release, I've released an 0.6c11 update at: http://pypi.python.org/setuptools/ It fixes an error when running the "sdist" command on a package with no README, and includes the 64-bit Windows fix that was promised in 0.6c10 but wasn't actually checked in to SVN. You can install the updated version using easy_install (or pip!), by asking for setuptools==0.6c11. The Fine Print -------------- (Note for users of Distribute: Distribute and setuptools use the same package name 'setuptools', and thus cannot both be present on the same sys.path (e.g. in the same virtualenv). If you wish to switch a given environment from Distribute to setuptools or vice versa, you will need to completely uninstall one before installing the other. If you currently have Distribute installed, please follow Distribute's uninstall instructions if you wish to reinstall setuptools.) Please report any bugs to the setuptools bug tracker at: http://bugs.python.org/setuptools/ For faster response to questions, please use the distutils-sig mailing list, rather than the tracker. Setuptools documentation can be found via links at http://pypi.python.org/pypi/setuptools#using-setuptools-and-easyinstall -- and the pages on the PEAK wiki now load much, much faster than they did a few months ago. (They're static cached pages now, rather than dynamically generated, unless you're actually logged into the wiki.)

1 0