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@colorstudy.com | http://blog.ianbicking.org