[Zope-dev] Re: ploneout - Or how using zc.buildout for a common
Zope2 project might look like
ianb at colorstudy.com
Mon Jan 29 15:13:03 EST 2007
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
More information about the Zope-Dev