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 | [EMAIL PROTECTED] | http://blog.ianbicking.org
_______________________________________________
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
