On Aug 30, 2010, at 1:50 PM, Jim Fulton wrote: > On Fri, Aug 27, 2010 at 4:23 PM, Gary Poster <gary.pos...@canonical.com> > wrote: >> >> On Aug 27, 2010, at 3:59 PM, Reinout van Rees wrote: >> >>> On 08/27/2010 04:12 PM, Gary Poster wrote: >>>> >>>> I realize that a system Python happened to work for you before. >>>> >>>> That's a bit awkward, because with pre-1.5.0 zc.buildout, using a system >>>> Python was not supported. >>>> >>>> Therefore, your recipe was not supported. >>> >>> "my recipe"? osc.recipe.sysegg is not something that *I* made, I'm just >>> using it. "Is not supported" sounds like a helpdesk telling me "linux is >>> not supported". >>> >>> And "not supported"? osc.recipe.sysegg installs the specific eggs I tell >>> it to find (in the system python) as develop eggs. A nice trick that works >>> pretty well. >> >> ...Not sure what to tell you there. Jim has been clear from the beginning >> that system Pythons were not supported with buildout. I added support. >> Anything before then happened to work. > > I'm not sure I agree with this. :)
LOL. Sorry to misrepresent. > Technically, you're right, in that > I didn't offer any sympathy or support for people who had trouble > using unclean Pythons (defined as Python installations that differ > from a build from source). Right, this is what I was referring to. > Still, I expected buildout to use anything found in the Python it was > bootstrapped with, with all of the advantages and disadvantages that > implied. :) OK. > This seemed the most conservative approach at the time > and didn't cost me anything because I've never found it burdonsome to > provide clean Python installes separate from the system Python. > > While, I think my decision was raesonable, I came to regret it. I > prefer the approach taken by virtualenv to provide isolation by > default and provide a way to relax it. > > My preferance is that buildout provide isolated and non-isolated modes > and that the isolation apply equally to recipes, extensions, and eggs > installed by parts. Having fought through all this, I really think having separate isolation controls for the buildout (buildout, recipes, extensions) versus the things that are built by parts is the right way to go. It's two very different domains, and the people writing the two kinds of code are often completely separate. > I'd be inclined to have buildout be non-islated > by default, for backwards compatibility, and switch the default in > buildout 2. As a meta comment, from the peanut gallery , I'm concerned about the buildout 2 plans (where "buildout 2" means "package name change") because they remind me of a couple of other similar historical changes that have permanently (or, at least, so far, often for years) divided communities. The forking is entirely your prerogative, of course. As to the practical issue of what to do now, here are options, working up to your stated preference. 1) Leave 1.5 and the trunk as it is, try to support osc.recipe.sysegg if someone directs me to the code, and move on, without a buildout 2. Unsurprisingly, that's my preference. (Post-weekend, I think I can see how to adapt the recipe Reinout listed to work with an isolated buildout, given the current way 1.5 works. I'd do the searching for eggs in a subprocess with the desired Python, and I suspect everything else would work out fine, with the added robustness of 1.5.0's general isolation. Since the recipe has no tests in the tarball and Google doesn't show me the sourcecode, I'm not yet encouraged to give it a whirl, but could be.) 2) Built eggs are non-isolated by default if you use zc.recipe.egg. Switching to z3c.recipe.scripts is an explicit gesture. However, I'm adjusting *other* recipes to use code from z3c.recipe.scripts to generate their scripts, and these (zc.recipe.testrunner and z3c.recipe.tag for now, z3c.recipe.i18n locally on my machine, djangorecipe intended to come possibly among others) are defaulting to isolation. I could make these other recipes default to not isolating. I'd regard that as a shame, because I think it is really nice for buildout to be able to be used with a system Python easily without having to know about special switches or anything else, but practically it would be pretty easy for me. 3) It would be more complex but doable to make all buildout bits (recipes, extensions, and buildout itself) default to not being isolated. Given the current architecture, which I have no desire to change myself, I think it would have to involve one bootstrap for an isolated environment and one bootstrap for a non-isolated environment, and then various changes within Buildout itself. I don't like this, but it is what I see would be needed to support the current version of osc.recipe.sysegg. 4) We can have unified isolation controls for buildout (+ recipes and extensions) and the built eggs. FWIW, I'm happy with option 1, and helping out with osc.recipe.sysegg if given some direction. I'm OK with option 2, and doing the work. I'm unhappy with option 3, but would try to do the work. I'd have to be further convinced about option 4. Gary _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
