Hi Philip, >> I've been recommending workingenv, and James Gardener has started >> promoting zc.buildout. > > Has he?
Only to Mike but I do think it could be the best long-term solution. There are a few rough edges at the moment though. >> I'd like to see one strategy laid out in the tutorials, with a link to >> the other approaches for advanced users. So the question is, which >> approach is most straightforward and reliable? > > I just tried buildout for the first time; I had it install Pylons. You > end up with a result similar to that of virtualenv, though with a > different directory layout: > > bin/ > buildout.cfg > develop-eggs/ > eggs/ > parts/ > > With all the Pylons dependencies installed in eggs/. No local version of > setuptools gets installed like virtual-python/workingenv. That's the nice thing, it is a complete sandbox, doesn't affect the system Python and doesn't need loads of symlinks like virtual env does. The only difference is that you can't use easy_install with buildout, you have to specify extra packages either properly via your Pylons project's setup.py or manually in the eggs option in buildout.cfg > I immediately noticed the lack of paster in the bin dir. From my quick > skimming of the buildout docs it seems like it should be there, but I > didn't find an obvious way of making that happen (though I am a total > buildout newb). Yes, it doesn't install scripts from dependent eggs unless they are listed in buildout.cfg. I consider this a bug too so I've written my own egg recipe which does install them. > I like buildout's ability to only go after the final release versions of > eggs. A number of folks (including Jim Fulton) have asked for this > feature in setuptools on distutils-sig. I think there's a chance of it > happening for setuptools 0.7, but this probably won't be for a while. That's useful, as is the download cache option which means you can cache all the downloaded eggs, check them into your repository and then the production version of your site can run entirely from the cached eggs which means you always know which versions you are using and if you need to reinstall an application after say a server crash you aren't reliant on all the eggs still being present on pypi. > I like the fact that virtual-python/workingenv pretty much leverage > setuptools to handle the eggs, whereas buildout is managing the eggs and > their paths on its own. The python executable it creates for you > actually hardcodes all the egg paths. This is really nice but one drawback is that the python script is just that, a script, not an executable which means it can't be used in #! lines. Again, the recipe I use creates an executable to execute the script to get around this problem (much like setuptools installs a .exe on Windows). > James has probably played with it a lot more, so I'm curious as to what > his experience was. Actually I've only played with it a bit but it is my favorite solution so far. I've just packaged up the recipe I use and released it as pylons_sandbox on the cheeseshop so it should give you an idea of what I'm thinking. http://cheeseshop.python.org/pypi/pylons_sandbox/0.1.0 Do you know a way to get setup.py to compile an executable? I can get it to compile a .so via the extensions mechanism but it would be nice if the launcher program could be built automatically. Cheers, James --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pylons-devel" group. To post to this group, send email to pylons-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en -~----------~----~----~----~------~----~------~--~---
