[Zope-dev] Re: ploneout - Or how using zc.buildout for a common Zope2 project might look like

[Ian Bicking]

Jim Fulton wrote:
> Ian Bicking wrote:
>> Martin Aspeli wrote:
>>> whit wrote:
>>>
>>>> actually, in my current workplace, workingenv is the standard way to 
>>>> set up one's dev environment.  but in the context of the previous 
>>>> statement, familar is perhaps a better word.
>>>
>>> I'm still not clear how widely used workingenv is? Is it "officially 
>>> endorsed" anywhere else?
>>
>> It steps more lightly than buildout does. 
> 
> What does that mean?

It implements less and relies more on what other tools already do.

>> It's also mostly equivalent in mechanism to virtual-python, which is 
>> used quite widely.  Both use setuptools conventions more closely than 
>> buildout does.  It would be nice if I could say "then you get access 
>> to all the setuptools-related management tools", except there are 
>> almost none :(  But if they *did* exist you'd get access to them ;)
> 
> I suggest that workingenv and buildout are both such tools.
> 
>> Build stuff seems surprisingly contentious.  The debate around 
>> setuptools itself has always been far more difficult than it should 
>> be; there's a lot of stop energy.  So the Python community as a whole 
>> is moving very slowly on this stuff.
> 
> I suggest that, other than contention, this is somewhat healthy.
> People with different goals will often need different tools and
> make different tradeoffs.

Sure, but I'd also like if there was a clear story for people doing this 
sort of stuff.  I hate the difficulty describing how to do this general 
stuff, especially when describing it to people who don't even know what 
their goals are and just need *one* good solution rather than a choice 
of solutions.  Which is to say, I'd rather we try to figure out... 
something, rather than just chock it up to different goals and go our 
separate ways.  I haven't yet figured out what that something is, and 
probably that's the hard part.

Maybe part of it is a clear and simple scaling from something fairly ad 
hoc (like a workingenv that you've manually installed stuff into) into 
something more formalized (like a buildout).  Casual and beginning users 
work best with something they can directly touch and inspect.  In a more 
formalized system it's better to have a central place that described 
intention and the full system -- the casual user probably hasn't figured 
out their intention or the full system until well after they've 
completed their task.

Of course, some of buildout's scope is outside of workingenv's -- like 
building non-Python libraries, and setting up specific application 
instances.  I think it's fine if non-Python libraries require a more 
advanced setup, but application instances are something I'd like to have 
a better story for.  (Indirectly I'm still trying to figure out the best 
way to create application instances for PasteDeploy apps too -- I have 
some stuff in there, but I'm not terribly happy with it, and I haven't 
figured out what instance creation should be attached to.)

-- 
Ian Bicking | ianb at colorstudy.com | http://blog.ianbicking.org