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 | [EMAIL PROTECTED] | http://blog.ianbicking.org
_______________________________________________
Zope-Dev maillist - [email protected]
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
