Mailman 3 July 2009 - Distutils-SIG

exclude a module, or can setuptools honor svn:ignore flag?
by Frank Hoffsümmer July 20, 2009

July 20, 2009

Hello I have a python project, 'myproject', that contains several packages. one of those packages, 'myproject.settings', contains a module 'myproject.settings.local' that is excluded from version control via 'svn:ignore' property. I would like setuptools to ignore this file when making a bdist or bdist_egg target. I have experimented with find_packages(exclude..) to no avail. Ideally I was hoping that only files that are not ignored by svn would be included. Is there a way to achieve the exclusion of my module? I am on a patched ( http://bugs.python.org/setuptools/issue64) version of setuptools trunk, with subversion 1.6. thanks for any insight you might have -frank

1 0

Re: [Distutils] Colour this bikeshed: Name for setuptools fork
by P.J. Eby July 20, 2009

July 20, 2009

At 11:12 AM 7/19/2009 +0200, Tarek Ziadé wrote: >That's very interesting but you previously said that you needed time >and/or someone >paying you to continue the work in this area. No, I said that was needed to get me to work on *setuptools*. Since you guys are doing that for me now, I don't have to think about all the hard, boring work that I felt I had to do first. ;-) If I do "Discovery" at all, it will be because it's fun and pleasing to me, without all the nasty stuff I didn't want to think about needing to be done first. I've wanted to do this sort of refactoring for some time, but felt like I had to take care of stability and all that first. I'm actually kind of hoping that if I make Discovery nice enough, somebody else will refactor setuptools to use it. ;-) (Or just replace setuptools with something better.) >So are you willing to bless us maintaining/working with you with these >new packages, >or is that going to be a PJE-locked thing again ? I would suggest that you not try to make plans based on what I am or am not doing, until and unless I've already done it. That way, you can't be disappointed. Since this will be a fun/hobby project for me, I am not at this making ANY commitments about when, what, or how. I do expect to be using Mercurial, though, and accepting feature patches as well as bug fixes. >just a question : > > discovery.unpack -- setuptools.archive_util, less distutils dependency > >how this will be 'less distutils dependent' ? I want discovery to have as close to zero dependence on distutils as possible because some OS distributors like to split out "development" tools and I'd prefer they not split up Discovery because it imports from distutils. So if possible, I would like Discovery to be 100% self-contained -- which means not importing distutils.error, distutils.log, etc., or at least having a fallback in the event those modules can't be imported (due to a python-devel package being missing).

7 11

Re: [Distutils] Distutils 2.7/3.1 and setuptools stack overflow
by P.J. Eby July 19, 2009

July 19, 2009

At 03:32 PM 7/19/2009 +0200, Martin v. Löwis wrote: >Hi Phillip, > >I have investigated the problem of mutual recursion between setuptools >and distutils a little. I read a message somewhere that you didn't >understand the problem, so here is my analysis: > >1. build_py.data_files gets accessed, and is delayed-computed in > setuptools >2. build_py tries to load the manifest, and goes to egg_info for that >3. egg_info invokes add_defaults for the manifest >4. manifest_maker.add_defaults invokes sdist.add_defaults >5. in response to issue 2279, add_defaults now also adds build_py > data_files and package_data to the default files. > >As a work-around, I have now copied the 2.6 code of sdist.add_defaults >into manifest_maker.sdist_add_defaults. I don't understand. Where did you do this? In setuptools or distutils? >In the long run, I think setuptools should revise its computation of >data_files. Couldn't you simply use distutils' get_data_files()? Setuptools supports an 'include_package_data' option that automatically includes any revision-controlled files found in package directories. Distutils doesn't. The somewhat-recursive aspect is that when an sdist is used instead of a checkout, the previous revision control info is not available, so setuptools must use the previously-computed list of included files in order to find out which files are "package data". It's possible that this could be resolved in some other way, but IIUC Tarek has already implemented a setuptools patch to fix this, which has been applied to the "Distribute" fork of setuptools. I am seriously considering simply blessing that fork *as* setuptools, at least with respect to the 0.6 maintenance branch, and turning over its stewardship to the Package Inquisition, or whatever they're calling themselves. ;-) ("The Society For Packaging Things On Top Of Other Things" would probably be another good Monty Python-inspired name for the group.)

3 2

idea - keeping package index code (in pip, distribute) separate
by Sridhar Ratnakumar July 19, 2009

July 19, 2009

Both easy_install and pip uses similar method to find download URLs for packages. They are not very unreliable - see the new issues in Distribute tracker: http://bitbucket.org/tarek/distribute/issues/?status=new&reported_by=srid Hence I suggest that we create a separate project containing just this indexing code .. and let Distribute and pip use it via install_requires. Thoughts? -srid

3 2

[Buildout] Download API and extends caching - please review
by Thomas Lotze July 19, 2009

July 19, 2009

As discussed before on this list, I've been working on an internal download API for zc.buildout that takes care of handling the download cache, offline mode, MD5 checks etc and is used for fetching configuration files (as specified by the buildout:extends option). I consider the feature finished and I'd be grateful if someone could review it before it gets merged to the trunk. The branch I've been developing this on is <svn://svn.zope.org/repos/main/zc.buildout/branches/tlotze-download-api>. Thank you. -- Thomas

3 4

Re: [Distutils] Colour this bikeshed: Name for setuptools fork
by P.J. Eby July 18, 2009

July 18, 2009

At 04:53 PM 7/17/2009 +0200, Lennart Regebro wrote: >2009/7/17 P.J. Eby <pje(a)telecommunity.com>: > > Setuptools was something I originally wrote for common requirements in my > > work projects... then expanded into a funded project to provide Chandler > > with a plugin infrastructure. These days, I don't have time to code on the > > projects I *enjoy* and *want* to code on... and setuptools as it stands > > today is not one of those projects. > >This is completely understandable, and a good reason not to work on >it. The problem is that you simultaneously have prevented others to >work on it, False. Jim Fulton has had commit privileges for ages (and has committed sizable chunks of code), and Ian Bicking would be equally welcome to them, if he asked. (Ian contributed the Python 2.6 egg for the 0.6c9 release, and of course he pioneered support for Subversion and Sourceforge downloads in easy_install.) And I'd seriously consider Philip Jenvey as well, as he's done a ton of Jython-compatibility work. In other words, people I know and trust to be qualified for the job are quite free to maintain it. If Jim or Ian wanted to "adopt" setuptools or become primary maintainers, I'd frankly jump at the opportunity! Mainly, I trust Jim and Ian because they're thorough, cautious, and sensitive to "legacy" issues. I know they're not going to go in and reverse years of policy until and unless they have a damn good understanding of both the old and the new requirements, and have a plan to address compatibility and migration. (Hell, I'd also consider the folks at Enthought, who (like Jim and Ian) have built sizable systems atop setuptools and had to deal with a nice variety of end-user configuration quirks. I would guess them to be equally requirements-educated and production-cautious.) However, AFAIK, nobody qualified for the job of setuptools maintainer actually *wants* the position, myself included. (This is not to say that such qualified persons do not exist, I'm just saying that I don't know of them at the moment.) But lack of qualified volunteers is not me "preventing" anyone doing anything. Obviously, I am not "preventing" anyone from forking it.

10 13

Re: [Distutils] [Distribute] project status
by P.J. Eby July 18, 2009

July 18, 2009

At 01:15 PM 7/18/2009 +0200, Tarek Ziadé wrote: >Hello, > >We are going to freeze our bug fix work on the code and focus on >testing/documenting the release that we are planning to publish at >PyPI asap. > >The list of bugs we've fixed are listed here : >http://bitbucket.org/tarek/distribute/wiki/bug_listing >If you feel that we forgot an important bug from the list we didn't >mirror yet, please let us know. Notice that we won't be able to fix >them >all now, and that we will have 0.6.x maintenance releases for that. Btw, does this changeset: http://bitbucket.org/tarek/distribute/changeset/52bb77ad5030/ Work on Python 2.3 on the Mac? platform.mac_ver() was not documented until 2.4; was it actually introduced in 2.3?

3 2

[distribute] Python 3 support checked in, and fucked everything up.
by Lennart Regebro July 18, 2009

July 18, 2009

OK, not a good start. I haven't used mercurial for long and I already hate it. I checked in the Python 3 support, which for some reason made the new python3 branch the main active branch. Which of course wasn't the intention. Also, an earlier name of the branch got added. I want that removed. Somebody is welcome to tell me how to fix this. I have no idea, and mercurial documentation doesn't help (and in fact gave absolutely no hint that this would happen). -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64

6 15

[Distribute] project status
by Tarek Ziadé July 18, 2009

July 18, 2009

Hello, We are going to freeze our bug fix work on the code and focus on testing/documenting the release that we are planning to publish at PyPI asap. The list of bugs we've fixed are listed here : http://bitbucket.org/tarek/distribute/wiki/bug_listing If you feel that we forgot an important bug from the list we didn't mirror yet, please let us know. Notice that we won't be able to fix them all now, and that we will have 0.6.x maintenance releases for that. The first release will ship the same package/modules and will overwrite an existing setuptools installation. The tasks we will do now are: - write a documentation on how to switch to distribute. This document will explain the steps to use the distribution in a setuptools-based setup.py project or in a zc.buildout environment. For the latter, this will probably require us to provide a custom bootstrap.py script. - write a documentation on how to uninstall distribute, if the user want to go back to setuptools. (it's a friendly fork, we don't want to mess things up) - write a roadmap document, explaining the plans for 0.7 and 0.8, so the people that are installing 0.6 will know where they are heading. - do extensive tests under various environment/contexts to see how things work, and to validate that the upgrade/install scenarii are working well. We will try to write functional tests for that so we can replay them. This is very important, especially because the test coverage in setuptools is very low right now. - produce a tarball archive so people that wish to help can try out on their side Once we feel that the code is ready and enough tested, we will publish 'Distribute 0.6 (or whatever the name become)' Except this release sometimes next week. Extra steps if we have time : - set up a buildbot - more documentation - improving test coverage Cheers Tarek -- Tarek Ziadé | http://ziade.org

1 0

Re: [Distutils] Colour this bikeshed: Name for setuptools fork
by P.J. Eby July 18, 2009

July 18, 2009

At 10:05 PM 7/17/2009 +0200, Hanno Schlichting wrote: >We will need to carefully look at what we want to do and how we do >it after some of the early strong emotional reactions have settled >down. Anyone who wants to rewrite setuptools from scratch or thinks >"easy_install must die" probably will be very disappointed by the >distribute fork. I'm glad to hear it; that makes it *much* more likely that I will simply bless some version of your package as the "official" setuptools 0.6 "final" series, and merge it back into my trunk whenever I get around to working on the 0.7 versions. (Which might even happen sooner if somebody else is keeping 0.6 fed and watered... thereby decreasing the "work factor" for me.) (Btw, I'm not sure if you really want to drop entry-points.txt from revision control, since ISTM a fresh checkout will not be able to run egg_info and rebuild it, unless you also add a hack to Distribution.get_command_class() so it (and any other setuptools commands it relies upon) can be found. If it seems to be working as-is, my guess is it's because an already-elsewhere-installed setuptools version on sys.path is providing the glue by way of *its* entry-points.txt. Try it and see!)

2 1