Re: [Distutils] Buildout status
2011/5/12 Kelsey Hightower : >> OK, given the discussion, I guess the easiest course for buildout would be >> for buildout 2 to support just distribute next (to simplify the code) >> and then work >> on transitioning to packaging. Buildout 1 would largely stay as it is with >> bug >> fixes. > > Tarek, correct me if I am wrong here, but 3rd party tools will need to > rely on distribute(setuptools) as packaging/d2 will never provide a > backwards compatible substitute or API. Packaging/d2 relies on > distribute as an external dependency. > > So in this case buildout2 will need to support distribute and later > add support for packaging down the road. > > So buildout2 will need packaging/d2 + distribute. There are three concerns: 1 - tools used by zc.buildout itself to manage packages. 2 - what's imported in setup.py in every project 3 - the project's dependencies for 1, packaging only can be used in the long term since we provide backward compat. for 2, if "setuptools" is imported there, it's required of course. same for 3. Now for how packaging installs setuptools-based project, it's dealt at our level. IOW, zc.buildout in the long term will only have to deal with the packaging APIS and not worry about what we do internally. Practically speaking, What's not clear yet is how we will inform that we need that extra Distribute dependency. Last, for 2 and 3, if the project uses some APIs that are supposed to see all installed packages for example, it'll have to use Distribute once it has added the PEP forward compat layer (unless Setuptools also adds it, so both will work) I hope this is clear :) Cheers Tarek -- Tarek Ziadé | http://ziade.org ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Buildout status
At 10:29 AM 5/12/2011 -0400, Jim Fulton wrote: On Thu, May 12, 2011 at 10:09 AM, Tarek Ziadé wrote: ... >>> - stop adding features so distutils2/packaging slowly takes over >> >> Absolutely. I couldn't agree more. Just understand that we're going >> to have to support old packages that import setuptools in their setup >> scripts indefinitely. That's one of the biggest challenges I see. >> Maybe packaging can (does?) provide a shim for this. > > As I said earlier, we do have backward compat in everything we do with > packages. That leads to ugly code in some places, but we have to. > > But as you said, there's the maturity problem... OK, given the discussion, I guess the easiest course for buildout would be for buildout 2 to support just distribute next (to simplify the code) and then work on transitioning to packaging. Buildout 1 would largely stay as it is with bug fixes. You should be aware of a few things going forward, with respect to compatibility. While Distribute includes many changes that are not in setuptools; the reverse is also true: setuptools includes bug fixes that are not currently fixed in Distribute. One important fix is rather complex, as there was a problem with build-time dependency recursion that manifested itself as multiple bug reports for multiple packages. This was fixed in setuptools, but the Distribute developers opted not to port the fix when it first came out a year or two ago, and AFAIK that has not changed. So, you should be aware that you may have some non-trivial merge work ahead, if you want to include those fixes into Distribute. In addition, Distribute contains various pieces of "anti-setuptools" code, in the sense that it deliberately attempts to prevent setuptools being installed or updated. I don't know if you care about that one way or the other, but you should be aware that it exists. (And of course, there is 2to3.) ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Buildout status
> OK, given the discussion, I guess the easiest course for buildout would be > for buildout 2 to support just distribute next (to simplify the code) > and then work > on transitioning to packaging. Buildout 1 would largely stay as it is with > bug > fixes. Tarek, correct me if I am wrong here, but 3rd party tools will need to rely on distribute(setuptools) as packaging/d2 will never provide a backwards compatible substitute or API. Packaging/d2 relies on distribute as an external dependency. So in this case buildout2 will need to support distribute and later add support for packaging down the road. So buildout2 will need packaging/d2 + distribute. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Buildout status
On Thu, May 12, 2011 at 10:09 AM, Tarek Ziadé wrote: ... >>> - stop adding features so distutils2/packaging slowly takes over >> >> Absolutely. I couldn't agree more. Just understand that we're going >> to have to support old packages that import setuptools in their setup >> scripts indefinitely. That's one of the biggest challenges I see. >> Maybe packaging can (does?) provide a shim for this. > > As I said earlier, we do have backward compat in everything we do with > packages. That leads to ugly code in some places, but we have to. > > But as you said, there's the maturity problem... OK, given the discussion, I guess the easiest course for buildout would be for buildout 2 to support just distribute next (to simplify the code) and then work on transitioning to packaging. Buildout 1 would largely stay as it is with bug fixes. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Buildout status
On Thu, May 12, 2011 at 3:28 PM, Jim Fulton wrote: > On Thu, May 12, 2011 at 6:56 AM, Tarek Ziadé wrote: >> On Wed, May 11, 2011 at 6:44 PM, Jim Fulton wrote: >>> On Wed, May 11, 2011 at 10:21 AM, Tarek Ziadé wrote: On Wed, May 11, 2011 at 3:21 PM, Jim Fulton wrote: ... Not sure to folllow. You want to port Setuptools into py3k... again ? If so, this was done already in Distribute, and you can join the project. >>> >>> I don't really want to join a project. I already have a number of >>> projects. >> >> But the work is not going to happen only into the zc.buildout tree, >> right ? > > No. If I do this, I'd work with Phillip Eby. > > If you tell me that distribute is being actively maintained, I'll use > distribute. What I've heard in the past is that distribute wasn't > being worked on. I'd interpreted this to mean that it wasn't being > maintained. Perhaps I misinterpreted. Again, if you assure me that it > is being maintained, I'll use it instead. I can't spend anymore the time on it regularly unfortunately, I have to make choice about my free time and I chose to work in the stdlib upcoming package. But I can assure the following (that what happened lately) : 1- anyone that wish to contribute a patch can do it, I give commiter writes for this 2- we are now several people that can push a release at PyPI. I can add more people if I know them 3- When I do releases, I do post-review of patches 4- Some other folks have enough knowledge now to do 3. There are a few patches pending that should be commited, and I am not following Setuptools activity as I used too by a lack of time, so there are probably a few commits to backport. I think that's less of a day of work altogether as far as I can see. I can spent this time real soon and do a release so we're up to date, but you or someone else would need to help in the future. I don't know if this is a superior approach to PJE's approach on maintenanceship, but it means that any big issue that would happen in the code will not be locked by a single person. For instance OS packagers have an access to it, and can work out problems they had downstream. I don't think we're anymore on the "no one can understand the code base" line. ... >> >> I so wished that we could have all worked together in the first >> place... > > What? I don't understand. You make it sound as if I refused to work > with you. If you are suggesting that I failed to contribute to > distribute or distutils2, you'll have to excuse me for choosing to > work on other projects. Buildout is just a consumer of setuptools (and > packaging in the future). Sorry for the confusion, I was not pointing any finger at you. "we" referred to all parties involved for packaging tools, setuptools, distutils, distribute. I was just indirectly saying that I also wished we did not forked and be able to get along. But I am still glad we did since we offered setuptools for py3. ... >> - what's going to happen when distutils2-based packages will be >> published ? are you going to add backward compat in setuptools, so >> redo what we did in d2 in reverse ? (this is planned in Distribute, so >> doubled-work again) > > What I said was that I wasn't going to support both. But if a project supports only distutils2 in the future, you cannot force it to use setuptools' metadata. Yet, it will express dependencies you need to deal with. (PEP 345) ... > > From talking to Phillip, I think he intends to update setuptools to > reflect new peps. Personally, I'd be happy to see it (and distribute) > just fix bugs and remain stable. I agree for bug fixing. In the meantime I also partially agree w/ PJE: package_resources should be able to see packages installed by distutils2, o/w that's not going to work well > > I'm totally on board with the move to packaging, but until all of the > packages that buildout needs to install switch away from setuptools, I > have to be able to provide setuptools support. So do we. Packaging supports the installation of setuptools-based projects, and also reading metadata from project installed by it. ... > > IOW, unfork. I would *love* *LOVE* to see that happen. Me too, as long as we have more than one person on board :) > >> - start to use in it, when possible, pieces of distutils2, so >> Distribute/Setuptools become PEP 345/PEP 376 aware > > sure. That's reasonable. First, buildout has to get under > control. That's my problem (and the problem of people graciously > helping me). > > >> - stop adding features so distutils2/packaging slowly takes over > > Absolutely. I couldn't agree more. Just understand that we're going > to have to support old packages that import setuptools in their setup > scripts indefinitely. That's one of the biggest challenges I see. > Maybe packaging can (does?) provide a shim for this. As I said earlier, we do have backward compat in everything we do with packages. That leads to ugly code in some places, but we have
Re: [Distutils] Buildout status
Hello, On 05/12/2011 03:28 PM, Jim Fulton wrote: If you tell me that distribute is being actively maintained, I'll use distribute. What I've heard in the past is that distribute wasn't being worked on. I'd interpreted this to mean that it wasn't being maintained. Perhaps I misinterpreted. Again, if you assure me that it is being maintained, I'll use it instead. I fixed a bug some weeks ago. https://bitbucket.org/tarek/distribute/issue/200/win-amd64exe-cannot-be-installed I sort of dropped the lead to PJE too. The result is that distribute had the release in about a week, setuptools is nowhere. -- Best regards, Adam GROSZER -- Quote of the day: The most incomprehensible thing about the world is that it is comprehensible. - Albert Einstein ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Buildout status
On May 12, 2011, at 09:28 AM, Jim Fulton wrote: >If you tell me that distribute is being actively maintained, I'll use >distribute. What I've heard in the past is that distribute wasn't >being worked on. I'd interpreted this to mean that it wasn't being >maintained. Perhaps I misinterpreted. Again, if you assure me that it >is being maintained, I'll use it instead. FWIW, if buildout 2 only supports setuptools, it'll be much less interesting to me. Debian and Ubuntu use distribute by default, as does all of my own personal projects. Cheers, -Barry signature.asc Description: PGP signature ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Buildout status
On Thu, May 12, 2011 at 6:56 AM, Tarek Ziadé wrote: > On Wed, May 11, 2011 at 6:44 PM, Jim Fulton wrote: >> On Wed, May 11, 2011 at 10:21 AM, Tarek Ziadé wrote: >>> On Wed, May 11, 2011 at 3:21 PM, Jim Fulton wrote: >>> ... >>> Not sure to folllow. You want to port Setuptools into py3k... again ? >>> If so, this was done already in Distribute, and you can join the >>> project. >> >> I don't really want to join a project. I already have a number of >> projects. > > But the work is not going to happen only into the zc.buildout tree, > right ? No. If I do this, I'd work with Phillip Eby. If you tell me that distribute is being actively maintained, I'll use distribute. What I've heard in the past is that distribute wasn't being worked on. I'd interpreted this to mean that it wasn't being maintained. Perhaps I misinterpreted. Again, if you assure me that it is being maintained, I'll use it instead. ... >>> Although, my suggestion would be to start digging into the >>> Distutils2/packaging project instead, since that will be in the >>> standard library, and backported in 2.x. >> >> When it's mature, I'll use it. > > Some of the code you need is usable today. "Some" isn't good enough. There's another issue that I'll mention below. > > examples: > > - easy_install's package index can be replaced by the index tool we have. > - browsing installed packages (the new PEP 376 and the old > setuptools/distutils standards) > - ... > > There are a few corner cases we don't deal with. For instance, we get > things installed as non-zipped egg. I think that would be a good > default for buildout2. > > But yeah, the code is not "mature" I guess, but it's driven by known > use cases for you, not new features we'll ask people to try out. And > it's going to be published in Python 3.3 in +1 year. Not sure what > your roadmap looks like but if buildout2 is a rewrite, by the time its > mature itself, 3.3 will be out imho Buildout needs setuptools/distribute in 2 ways: 1. Buildout uses it to download and install packages 2. Buildout makes it available in the path when installing source distributions that import setuptools. It's going to be a *long* time before this need goes away. For a while, I was thinking of forking distribute to address #1, but that wouldn't address #2, which is just as importasnt. ... >>Regardless, I fully expect to use >> Packaging when it's ready, but I'm stuck with setuptools/distribute >> now. I so wish that fork hadn't been done. > > I so wished that we could have all worked together in the first > place... What? I don't understand. You make it sound as if I refused to work with you. If you are suggesting that I failed to contribute to distribute or distutils2, you'll have to excuse me for choosing to work on other projects. Buildout is just a consumer of setuptools (and packaging in the future). ... > But the reality is that some projects can run under Python 3 thanks to > Distribute. True, including buildout. > It's now used in most major Linux distributions, and you > saying "I will not support anything else that setuptools in buildout2" > does not sound right to me. By taking the road you've mentioned, it > seems to me that it's going to be more work and trouble that you > expect because: > > - you are going to re-do all the py3 porting we already did, and that > needs backward compatibility w/ distribute, because some people use > it for the extra python3 features we added > - you are going to maintain several branches if you don't use 2to3 > - what's going to happen when distutils2-based packages will be > published ? are you going to add backward compat in setuptools, so > redo what we did in d2 in reverse ? (this is planned in Distribute, so > doubled-work again) What I said was that I wasn't going to support both. Again, if you assure me that distribute is being maintained, then I'll avoid the work of porting setuptools to Python 3 and just use distribute. OTOH, if you tell me I have to wait for "packaging" to be widely adopted, well, that's just not going to cut it. > A simple direction in my opinion would be: > > - make sure all stuff done on setuptools lately that were neglected on > distribute side get merged back - so we really have 100% identical > behavior that works under py3 I soo f%$#ing hate the fork. > that's *way* less work. > - use when possible, pieces of distutils2 in buildout2, since we > target backward compat for all our APIs. > > Because as far as I know, the Setuptools project is just doing > bugfixing. I don't think there are yet new features in it. I consider > that all setuptools-related technologies are now superseded by the new > stuff we do in packaging (that greatly inherit from them) >From talking to Phillip, I think he intends to update setuptools to reflect new peps. Personally, I'd be happy to see it (and distribute) just fix bugs and remain stable. I'm totally on board with the move to packaging, but until all of the pa
Re: [Distutils] Buildout status
On Wed, May 11, 2011 at 6:44 PM, Jim Fulton wrote: > On Wed, May 11, 2011 at 10:21 AM, Tarek Ziadé wrote: >> On Wed, May 11, 2011 at 3:21 PM, Jim Fulton wrote: >> ... >> Not sure to folllow. You want to port Setuptools into py3k... again ? >> If so, this was done already in Distribute, and you can join the >> project. > > I don't really want to join a project. I already have a number of > projects. But the work is not going to happen only into the zc.buildout tree, right ? > >> Or you want to copy our work from Distribute back into Setuptools ? >> I would not mind of course, merging back the 2 projects would be >> awesome -- but I have no hopes on this. > > It's possible that I could reuse that work. I'd rather port to 2&3 > rather than 3. That is, I'd rather not rely on 2to3 at deployment > time. I find installing distribute in Python 3 to be really annoying > due to the spew from 2to3. I also find the 2to3 development model > really unattractive. The major benefit is that you don't have to maintain separate branches for py3. Another thing is that you often don't have to deal with 2to3 internals, as you just adapt your code to be 2to3 friendly I agree that extending 2to3 is tough, but that almost never occur. If it occurs, you just need to ask Lennart ;) And the benefits are larger than going manually. We tried ! I don't see the extra spew at install time as a problem. > >> Although, my suggestion would be to start digging into the >> Distutils2/packaging project instead, since that will be in the >> standard library, and backported in 2.x. > > When it's mature, I'll use it. Some of the code you need is usable today. examples: - easy_install's package index can be replaced by the index tool we have. - browsing installed packages (the new PEP 376 and the old setuptools/distutils standards) - ... There are a few corner cases we don't deal with. For instance, we get things installed as non-zipped egg. I think that would be a good default for buildout2. But yeah, the code is not "mature" I guess, but it's driven by known use cases for you, not new features we'll ask people to try out. And it's going to be published in Python 3.3 in +1 year. Not sure what your roadmap looks like but if buildout2 is a rewrite, by the time its mature itself, 3.3 will be out imho > >> I believe it provides all the features buildout needs. And if not we >> should add them > > Buildout needs entry points. Entry points are just a feature on the top of browsable metadata of installed packages. The browsable part is already provided by d2. The installation of custom metadata is going to be done this summer during the GSOC, Basically, a CUSTOM file in the metadata directory. With a backward compat layer to install entry point as custom metadata. In a new Python3.3/packaging based projects, people will be able to add in their setup.cfg file: [metadata] X-Entry-Points = group:name = here.it.is And this will be copied in project.dist-info/CUSTOM In fact the plan is to *publish* setup.cfg to PyPI so tools will be able to read it without downloading anything ! For you, it means that you could use a single API to browse metadata for every installed project, whether they are setuptools-based or distutils2-based. >Regardless, I fully expect to use > Packaging when it's ready, but I'm stuck with setuptools/distribute > now. I so wish that fork hadn't been done. I so wished that we could have all worked together in the first place... On my side, the plan was to extend Distribute but that did not happen there, as we discussed the options in the Language Summit(s) and imo that was a good decision. Now I am looking forward to the new tools. But the reality is that some projects can run under Python 3 thanks to Distribute. It's now used in most major Linux distributions, and you saying "I will not support anything else that setuptools in buildout2" does not sound right to me. By taking the road you've mentioned, it seems to me that it's going to be more work and trouble that you expect because: - you are going to re-do all the py3 porting we already did, and that needs backward compatibility w/ distribute, because some people use it for the extra python3 features we added - you are going to maintain several branches if you don't use 2to3 - what's going to happen when distutils2-based packages will be published ? are you going to add backward compat in setuptools, so redo what we did in d2 in reverse ? (this is planned in Distribute, so doubled-work again) A simple direction in my opinion would be: - make sure all stuff done on setuptools lately that were neglected on distribute side get merged back - so we really have 100% identical behavior that works under py3 that's *way* less work. - use when possible, pieces of distutils2 in buildout2, since we target backward compat for all our APIs. Because as far as I know, the Setuptools project is just doing bugfixing. I don't think there are yet new fe
Re: [Distutils] Buildout status
On Wed, May 11, 2011 at 10:21 AM, Tarek Ziadé wrote: > On Wed, May 11, 2011 at 3:21 PM, Jim Fulton wrote: > ... > Not sure to folllow. You want to port Setuptools into py3k... again ? > If so, this was done already in Distribute, and you can join the > project. I don't really want to join a project. I already have a number of projects. > Or you want to copy our work from Distribute back into Setuptools ? > I would not mind of course, merging back the 2 projects would be > awesome -- but I have no hopes on this. It's possible that I could reuse that work. I'd rather port to 2&3 rather than 3. That is, I'd rather not rely on 2to3 at deployment time. I find installing distribute in Python 3 to be really annoying due to the spew from 2to3. I also find the 2to3 development model really unattractive. > Although, my suggestion would be to start digging into the > Distutils2/packaging project instead, since that will be in the > standard library, and backported in 2.x. When it's mature, I'll use it. > I believe it provides all the features buildout needs. And if not we > should add them Buildout needs entry points. Regardless, I fully expect to use Packaging when it's ready, but I'm stuck with setuptools/distribute now. I so wish that fork hadn't been done. > I think it boils down to: we should *all* work together in the > Distutils2/packaging project for all the basic packaging features we > need in third-party tools. I have lots of interesting projects I am working on and want to work on. I have no interest in making packaging a career. I'll use Packaging when it's ready. In the mean time, lots of people need buildout to work with Python 3 today. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Buildout status
On Wed, May 11, 2011 at 3:21 PM, Jim Fulton wrote: ... > > - Support for both setuptools and distribute > > I'm going to support one, or the other, or neither. I'm in a tough > spot. Distribute, which was created because setuptools wasn't being > maintained, is no longer being maintained, except there was a recent > release. Distribute is not as active as it was because we focus on the stdlib, but some people are working on it and doing releases. And we are planning to use it as a bridge for Python 3.3 new Distutils2 adoption by adding forward-compatibility for the new dist-info format. But in any case, if there's a bug, feel free to provide a patch, and it will be commited, then released. OSS ftw. > Setuptools, which is being maintained, doesn't work with Python 3. ha ha, that is such a funny statement: it's more maintained than Distribute but does not work with Python 3 :) > (I was thinking about forking distribute to eliminate the > dependency, but after further consideration, I don't think that's a > good idea, as one of these is needed to build source releases that > depend on them.) > My current leaning is toward porting setuptools to > 2&3 and supporting only setuptools. Not sure to folllow. You want to port Setuptools into py3k... again ? If so, this was done already in Distribute, and you can join the project. Or you want to copy our work from Distribute back into Setuptools ? I would not mind of course, merging back the 2 projects would be awesome -- but I have no hopes on this. Although, my suggestion would be to start digging into the Distutils2/packaging project instead, since that will be in the standard library, and backported in 2.x. I believe it provides all the features buildout needs. And if not we should add them I think it boils down to: we should *all* work together in the Distutils2/packaging project for all the basic packaging features we need in third-party tools. Cheers Tarek > > Jim > > -- > Jim Fulton > http://www.linkedin.com/in/jimfulton > ___ > Distutils-SIG maillist - Distutils-SIG@python.org > http://mail.python.org/mailman/listinfo/distutils-sig > -- Tarek Ziadé | http://ziade.org ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Buildout status
On 11/05/2011 14:21, Jim Fulton wrote: While the current release of buildout 2 has all the features from 1.5, future releases will not. Buildout has to get simpler, That would be good for everyone :-) has to take over maintenance. Assuming the former, I plan to eliminate some high maintenance features, including: - Support for multiple Python interpreters within a single buildout Yay! - Partial isolation from site packages and site.py -0 - It's a nice idea, and it'd be great to rely on some stuff from system python (especially when that's Enthought's Python Distribution) or Debian/Ubuntu/Red Hat packages when libraries are hard to compile, but this seems to work fine in Buildout's "non-isolated" mode, right? (ie: if I say I want fancylib 1.3, and the system has 1.2, Buildout will try and install?) certain what the default should be. I previously thought buildout should switch to being isolated by default, but given the popularity of using buildout with virtualenv, I'm leaning towards making isolation optional.) I think people only use virtualenv with buildout because it isn't isolated by default. z3c.recipe.scripts will be spun off to a separate project along with it's support code currently living in the zc.buildout package. I'll to whatever I can, by providing hooks, to support this recipe, but the maintenance of this feature has to move out of buildout. +0 - Support for both setuptools and distribute I'm going to support one, or the other, or neither. Neither would get my vote, but then I suspect maintaining the needed subset of both to do the things you need to do may be a lot of work :-/ Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
[Distutils] Buildout status
Buildout has become too complex for me to maintain. Two factors in particular have increased it's complexity to the breaking point, the isolation machinery introduced in 1.5 and the code to support the fork of setuptools. Let me be clear about 1.5: I really *really* appreciate the effort Gary Poster put in to that release. I don't fault his effort, given it's goals, I've just decided that the goals were too ambitious. I recently released 2.0.0a1 for Python 3. Not all tests pass under Python 2 or 3, but enough pass to make this usable with Python 3. The next phase of work will probably involve responding to problems people report with this release. (So far, it's been much quieter than I expected.) After that, I'll get going on the version 2 release in earnest. In the mean time, people will have some time to respond to what I say next, which may be controversial. :) While the current release of buildout 2 has all the features from 1.5, future releases will not. Buildout has to get simpler, or someone else has to take over maintenance. Assuming the former, I plan to eliminate some high maintenance features, including: - Support for multiple Python interpreters within a single buildout - Partial isolation from site packages and site.py Buildout will have an "isolated" mode. In this mode, it will exclude directories from the path that are added by site.py. (I'm not certain what the default should be. I previously thought buildout should switch to being isolated by default, but given the popularity of using buildout with virtualenv, I'm leaning towards making isolation optional.) z3c.recipe.scripts will be spun off to a separate project along with it's support code currently living in the zc.buildout package. I'll to whatever I can, by providing hooks, to support this recipe, but the maintenance of this feature has to move out of buildout. - Support for both setuptools and distribute I'm going to support one, or the other, or neither. I'm in a tough spot. Distribute, which was created because setuptools wasn't being maintained, is no longer being maintained, except there was a recent release. Setuptools, which is being maintained, doesn't work with Python 3. (I was thinking about forking distribute to eliminate the dependency, but after further consideration, I don't think that's a good idea, as one of these is needed to build source releases that depend on them.) My current leaning is toward porting setuptools to 2&3 and supporting only setuptools. Jim -- Jim Fulton http://www.linkedin.com/in/jimfulton ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
