[Zope-dev] Re: ploneout - Or how using zc.buildout for a common Zope2 project might look like

[Ian Bicking]

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