Jim Fulton wrote:
Ian Bicking wrote:
What I would *like* the distinction between workingenv and buildout to be is that workingenv is interactive (i.e., install with easy_install) and buildout is declarative (i.e., specify your environment with buildout.cfg).
Well said. I was looking for a way to bring this up in the discussion. This is a key difference.
When you use workingenv, how to you reproduce an existing workingenv? Is there something you can check in and later check out to get the same workingenv? Or is this just not in scope?
Maybe it should be out of scope, but I have built something into workingenv for it. You specify a file or URL with --requirements, a text file of things to install. You can also indicate --find-links and --editable in the file, as well as refer to another requirements file. The files look like: Pylons==0.8.2 # Adds several eggs and links that aren't on PyPI: -f http://pylonshq.com/download/0.8.2/ ZPTKit SQLObject==0.7.2 Then it will install all these packages. You might then put this at http://svn.myrepo.org/svn/projects/pylons_project.txt and then create another like: -r http://svn.myrepo.org/svn/projects/pylons_project.txt -f http://svn.myrepo.org/svn/projects/project_index.html -e MyProject This would set up the basic Pylons environment, but also add an editable version of MyProject into src/, including activating the file. (Notably MyProject *should* require Pylons and the other packages, seemingly rendering the pylons_project.txt useless, but probably *shouldn't* require exactly Pylons==0.8.2 because then you'd have to break that requirement to even test if such an exacting requirement was actually true.) workingenv also saves some of these settings (like the requirements file) so you can rerun it on a directory. If the requirements file had changed you'd get the updates, or if workingenv had changed it'd rewrite its files. Ideally you'll switch things around, rerun your tests, do some development, and once you've reached a stable state push those changes back into the requirements file. Another motivation for this was to make a simple command for people to try out a new framework, like: wget http://svn.colorstudy.com/home/ianb/workingenv/workingenv.py # You might also have several files attached to specific tutorials or # use cases: python workingenv.py \ -r http://some-framework.org/requirements.txt MyProject cd MyProject source bin/activate cd src paster create -t some_framework MyCode cd MyCode paster serve development.ini And they'd have an editable hello world at that point pretty reliably, without any system dependencies that might make the installation finicky. I had this bootstrapping idea in mind when I added --requirements, I wasn't really thinking much about deployment. It doesn't work well for things like database drivers (which are often needed for tutorials), which are often hard to install with easy_install; this is probably why I should make --site-packages default to on, and then just tell developers to use --no-site-packages to tests their requirements files. But anyway, with the goal of bootstrapping new developers without having to explain the tedious details of Python's packaging conventions, I think workingenv does reasonably well. -- Ian Bicking | ianb@colorstudy.com | http://blog.ianbicking.org