primco wrote: > What's your feeling about PJE basically saying workingenv was an > unsupported hack? He seems to back the approach of zc.buildout more.
Well, I wish he would support the small number of things that would make my setuptools monkeypatching unnecessary. I should poke him about that again. I guess he feels that an alternate site.py is a hack, but I dunno... it feels fairly natural to me. Though Python's site.py has grown too much stuff, which makes it hard to implement alternative site.py's. But not that hard. > In the posts I've read, PJE seems to recommend using only the > setuptools features to get isolated package installs. To me, the lower- > level approach you've taken that deals with the platform-specific > issues inherent in python is more straightforward (although to a > newbie, all the site.py hacking is probably bewildering). The site.py changes are basically not including site-packages -- but once you've imported the system site.py it's too late to exclude it, so I had to replace it. The actual contents closely match the system site.py. I think PJE is naturally more inclined to declarative systems, and that's probably the biggest difference between workingenv and zc.buildout -- in workingenv you have your environment and you do stuff to it, while in zc.buildout you declare how you want your environment to be and it makes it. Declarative seems more verifiably correct -- everytime you run it, it comes out exactly the same, summarizing everything in one cohesive file. That's nice, but it only really works when you know what exactly you want. And few people know what exactly they want -- at least, I don't know. I prefer getting the working system, and then figuring out how to describe it. Maybe another issue PJE has is that I don't think he likes easy_install, and so prefers something that doesn't rely on it so heavily. But I'm not sure. > This may be off topic but I keep running into these issues with Pylons > because of the large number of dependencies and rapid changes in the > versions of software throughout the dependency tree. I've been forced > to learn more about setuptools than I'd like just to manage my > development environment and release process in a way I'm comfortable > with. You can't always run off the head revision of 15 packages. At > some point you have to freeze it and release it. One idea with workingenv is the --requirements file, where you can indicate very exact (presumably tested) versions of packages. Then you don't have to put such exact changes in your actual application -- which is nice, because typically those requirements aren't actually true, but you can't determine forward compatibility until new versions come out. So instead of having to update your application when you determine more specific requirements, you just update a text file describing your particular needs. Getting back to the describing part, it would be nice to be able to build a requirements file from a working installation. I suppose this would be fairly simple, really -- just run through the eggs. Er... there's a tool for doing egg stuff... yeah, yolk: http://tools.assembla.com/yolk/ -- it has most all of what would be needed right now, though it would need some minor tweaks to produce the right file format. -- Ian Bicking | [EMAIL PROTECTED] | http://blog.ianbicking.org --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~----------~----~----~----~------~----~------~--~---
