Martin Aspeli wrote:
Jim Fulton wrote:
[foo]
recipe=zc.recipe.egg
eggs = egg1 egg2 ...
interpreter = mypy
extra-paths = path-to-your-instance/lib/python
scripts = mypy
This is great :) I used eggs = ${instance:eggs} to make sure it has the
same eggs as our
Martin Aspeli wrote:
Unless Utopia really exists I think developers all have their own
thoughts about setting up their development environment.
Maybe. Except if we (the plone core developers) use ploneout then we are
all using the same environment, and we duplicate less work.
Same
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
Jim Fulton wrote:
Similarly, say I had two applications, one in Zope and one in Pylons,
part of the same deployment (possibly interwoven using wsgi). If I
installed elementtree as an egg in buildout.cfg, I'd expect it to be
available to both. If that means patching some of pylon's confg files
On Jan 29, 2007, at 2:03 PM, Ian Bicking wrote:
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
On Jan 29, 2007, at 2:25 PM, Ian Bicking wrote:
Jim Fulton wrote:
Similarly, say I had two applications, one in Zope and one in
Pylons, part of the same deployment (possibly interwoven using
wsgi). If I installed elementtree as an egg in buildout.cfg, I'd
expect it to be available to
Jim Fulton wrote:
Ian Bicking wrote:
Martin Aspeli wrote:
whit wrote:
actually, in my current workplace, workingenv is the standard way to
set up one's dev environment. but in the context of the previous
statement, familar is perhaps a better word.
I'm still not clear how widely used
whit wrote:
Jim Fulton wrote:
whit wrote:
...
Specific use cases would help to guide this.
the main usecase for me is the following... hanno writes a recipe for
plone, and I want to use that recipe as part of setting up a
openplans development environment (for example inside my workingenv
Martin Aspeli wrote:
Eggs exist to pkg_resources (the runtime portion of setuptools) simply
by being available on a path. E.g., if you have lib/python/ on the
path, and lib/python/Foo-1.0.egg/ exists, then if you do
pkg_resources.require('Foo') that will add lib/python/Foo-1.0.egg/ to
the
Martin Aspeli wrote:
This thread is getting rather long... :)
But except for the interaction of workingenv and buildout, which I'm not
smart enough to say anything useful about, we are almost finished ;)
- There is a 2.5 branch of ploneout
(http://svn.plone.org/svn/ploneout/branches/2.5)
Martin Aspeli wrote:
whit wrote:
actually, in my current workplace, workingenv is the standard way to set
up one's dev environment. but in the context of the previous statement,
familar is perhaps a better word.
I'm still not clear how widely used workingenv is? Is it officially
endorsed
Ian Bicking wrote:
...
I would assume that buildout is specifically disabling easy_install's
updating of easy-install.pth
WRT egg installation, buildout follows easy_install's multi-version model.
It installs eggs in such a way that multiple versions can be installed
at the same time. As
Jim Fulton wrote:
The first step to compatibility is deciding what it means. :)
I'm all in favor of workingenv/buildout compatibility.
I'd like to see some specifics of how people would like
to use workingenv amd buildout together. I have some guesses,
but I'd rather hear people say what they
whit wrote:
...
Specific use cases would help to guide this.
the main usecase for me is the following... hanno writes a recipe for
plone, and I want to use that recipe as part of setting up a openplans
development environment (for example inside my workingenv that I've been
developing w/out
whit wrote:
Jim Fulton wrote:
...
zc.buildout is in no way zope specific. Can a Zope developer not
develop a tool without it being stamped as zope specific?
maybe... maybe not. When a developer struggles with more than one
tool from the same general source, it matters little to them whether
Ian Bicking wrote:
Martin Aspeli wrote:
...
If lib/python/Foo-1.0.egg/ is on the path to start with you can
import from it directly.
This is what zc.reipe.egg does I believe.
It activates (i.e., adds eggs to the path) in the scripts. I think
setuptools' egg activation will be
Ian Bicking wrote:
Martin Aspeli wrote:
whit wrote:
actually, in my current workplace, workingenv is the standard way to
set up one's dev environment. but in the context of the previous
statement, familar is perhaps a better word.
I'm still not clear how widely used workingenv is? Is it
Martin Aspeli wrote:
Jim Fulton wrote:
The first step to compatibility is deciding what it means. :)
I'm all in favor of workingenv/buildout compatibility.
I'd like to see some specifics of how people would like
to use workingenv amd buildout together. I have some guesses,
but I'd rather hear
Jim Fulton wrote:
Martin Aspeli wrote:
Jim Fulton wrote:
The first step to compatibility is deciding what it means. :)
I'm all in favor of workingenv/buildout compatibility.
I'd like to see some specifics of how people would like
to use workingenv amd buildout together. I have some guesses,
- ploneout (http://svn.plone.org/svn/plone/ploneout/trunk) is really
an environment that Plone 3 core developers could (should?) use as a
consistent way of setting up a Zope 2.10 instance with Plone 3 and all
dependencies. It uses svn:externals quite extensively to pull in Plone's
source
Martin Aspeli wrote:
Jim Fulton wrote:
Martin Aspeli wrote:
Jim Fulton wrote:
The first step to compatibility is deciding what it means. :)
I'm all in favor of workingenv/buildout compatibility.
I'd like to see some specifics of how people would like
to use workingenv amd buildout together.
Jim Fulton wrote:
[foo]
recipe=zc.recipe.egg
eggs = egg1 egg2 ...
interpreter = mypy
extra-paths = path-to-your-instance/lib/python
scripts = mypy
This is great :) I used eggs = ${instance:eggs} to make sure it has the
same eggs as our Zope instance, seems to
Martin Aspeli wrote:
I don't have a usecase for executing the scripts with any python
interpeter other than the one which ran setuptools to generate them, and
therefore don't care for the hard-wired path manipulation
I would agree that having to mangle multiple scripts is annoying. On the
Martin Aspeli wrote:
I don't have a usecase for executing the scripts with any python
interpeter other than the one which ran setuptools to generate them, and
therefore don't care for the hard-wired path manipulation
I would agree that having to mangle multiple scripts is annoying. On
the
Jim Fulton wrote:
whit wrote:
I'm not clear on what the advantage would be. I'm probably missing
some use cases. I think they are both valid approaches to the problem.
my main usecase is to be able to use buildouts in a workingenv without
having to rewrite the recipes... right now, I have
Ian Bicking wrote:
It would be a concern if, for instance, Plone started depending on
buildout recipes for installation, without plain distutils recipes. Of
course right now there are no distutils recipes for old-style Products.
So actually it's an active issue -- if buildout enables Plone to
Rob Miller wrote:
honestly, it seems to me that buildout tries to do too much.
That's ok. I often don't need the big hammer that buildout is. That's
when I tend to use workingenv (even if it's' just for trying out whether
something's easy_install'able)
it's
trying to handle both
whit wrote:
I'm not clear on what the advantage would be. I'm probably missing
some use cases. I think they are both valid approaches to the problem.
my main usecase is to be able to use buildouts in a workingenv without
having to rewrite the recipes... right now, I have to do one or the
Ian Bicking wrote:
Jim Fulton wrote:
I actually tried to do this once before with zc.buildout, but I didn't
get far -- probably a result of lack of effort and lack of familiarity
with the overall stack. But I also recognize lots of the questions
about stuff like the zope.conf file and Data.fs
Ian Bicking wrote:
Jim Fulton wrote:
If *Plone* becomes incompatible with workingenv that'd be bothersome
I agree.
But if a buildout is incompatible, eh... who knows,
I would hope that buildout would not have to be compatible with
workingenv, whatever that means, in order for Plone to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jim Fulton wrote:
Ian Bicking wrote:
Jim Fulton wrote:
If *Plone* becomes incompatible with workingenv that'd be bothersome
I agree.
But if a buildout is incompatible, eh... who knows,
I would hope that buildout would not have to be compatible
Tres Seaver wrote:
I don't think buildout's default locations would be called sensible by
anybody except the folks who wrote it.
I think a lot of this may have to do with sensible defaults; most (all?)
of this is settable via options in buildout.cfg, which is reassuring at
least.
Here
I don't have a usecase for executing the scripts with any python
interpeter other than the one which ran setuptools to generate them, and
therefore don't care for the hard-wired path manipulation
I would agree that having to mangle multiple scripts is annoying. On the
other hand, I find the
whit wrote:
Martin Aspeli wrote:
Philipp von Weitershausen wrote:
This is awesome, and by that I don't mean the fact that we have a
plone buildout, but that we actually have Zope 2 recipes for
buildout. I hope they can be moved to svn.zope.org for further
development to benefit the whole
Philipp von Weitershausen wrote:
The point is that buildout *already* handles eggs. There's really no
point for having an extra layer on top of buildout. The zc.recipe.egg
recipe can install any egg (as a development one or not) in an automated
fashion, which is exactly what you'd want from a
Philipp von Weitershausen wrote:
whit wrote:
Martin Aspeli wrote:
Philipp von Weitershausen wrote:
This is awesome, and by that I don't mean the fact that we have a
plone buildout, but that we actually have Zope 2 recipes for
buildout. I hope they can be moved to svn.zope.org for further
On Thu, 25 Jan 2007 12:45:26 -0800, Martin Aspeli [EMAIL PROTECTED] wrote:
Plone stinks!
It's like a fine cheese.
--
Alexander Limi ยท http://limi.net
___
Zope-Dev maillist - Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
** No
Philipp von Weitershausen wrote:
whit wrote:
Martin Aspeli wrote:
Philipp von Weitershausen wrote:
This is awesome, and by that I don't mean the fact that we have a
plone buildout, but that we actually have Zope 2 recipes for
buildout. I hope they can be moved to svn.zope.org for further
whit wrote:
Not everybody likes the activate dance. With buildout, you don't need
it. The recipes make sure that the scripts that get installed into the
buildout's 'bin' directory have the right PYTHONPATH set and have
access to the eggs you requested for the buildout.
is there really a
I hate to jump into this thread but I'll make a few comments.
On Jan 25, 2007, at 5:13 PM, whit wrote:
Philipp von Weitershausen wrote:
whit wrote:
Martin Aspeli wrote:
Philipp von Weitershausen wrote:
This is awesome, and by that I don't mean the fact that we have
a plone
On Jan 25, 2007, at 5:09 PM, Ian Bicking wrote:
Whit pointed me to this thread.
Yeah, someone pointed me to it too. :)
I won't reply to specifics, but maybe
just describe what we're doing (and planning to do), and how
workingenv
differs from zc.buildout.
I'll avoid responding to
On Jan 25, 2007, at 5:44 PM, Ian Bicking wrote:
workingenv is development-centric, while buildout is deployment-
centric. This does not necessarily mean the best tool for the
job, because focusing on development and ignore deployment isn't a
good job, nor the other way around.
buildout
Jim Fulton wrote:
If *Plone* becomes incompatible with workingenv that'd be bothersome
I agree.
But if a buildout is incompatible, eh... who knows,
I would hope that buildout would not have to be compatible with
workingenv, whatever that means, in order for Plone to be compatible.
Then
Rob Miller wrote:
honestly, it seems to me that buildout tries to do too much. it's trying to
handle both repeatable deployment recipes AND providing a sandbox within which
to run things. there may not be a point to having an extra layer on top of
buildout, but buildout sure does seem to me
Jim Fulton wrote:
I actually tried to do this once before with zc.buildout, but I didn't
get far -- probably a result of lack of effort and lack of familiarity
with the overall stack. But I also recognize lots of the questions
about stuff like the zope.conf file and Data.fs that still seem
Martin Aspeli wrote:
Rob Miller wrote:
honestly, it seems to me that buildout tries to do too much. it's
trying to handle both repeatable deployment recipes AND providing a
sandbox within which to run things. there may not be a point to
having an extra layer on top of buildout, but
Martijn Faassen wrote:
Hey,
Just some feedback in case you haven't gotten this already: I have
problem running bin/buildout as it seems to fail getting workingenv.py
from the cheeseshop:
zc.buildout.easy_install: Getting new distribution for workingenv.py=0.3
Page at
Martin Aspeli wrote:
I just emailed Hanno a few questions, but I thought I'd post them here
as well for further discussion:
- Is it so that I should check out ploneout, run boostrap.py, then
../bin/buildout.sh for each project? Or can I somehow use the same
checkout of ploneout for
I only know the answer for a few of these...
Martin Aspeli wrote:
- In my workingenv (i.e. when I've done source bin/activate) I had
some trouble using 'paster', because it couldn't find various eggs,
e.g. ZopeSkel, Paste, PasteScript, PasteDeploy and Cheetah. What's
annoying is that I had
Martijn Faassen wrote:
Hey,
I only caught this message earlier today, but this is really cool! It's
really nice to see some zope 2 recipes and I hope they indeed will end
up on svn.zope.org soon!
Your workingenv recipe sounds very interesting and I should try this
soon. Does it allow
Hi,
Martijn Faassen wrote:
Hey,
I only caught this message earlier today, but this is really cool! It's
really nice to see some zope 2 recipes and I hope they indeed will end
up on svn.zope.org soon!
I have sent my contributer agreement per snail-mail last week to Zope
Corp. so it might
Martijn Faassen wrote:
Hey,
I only caught this message earlier today, but this is really cool! It's
really nice to see some zope 2 recipes and I hope they indeed will end
up on svn.zope.org soon!
Your workingenv recipe sounds very interesting and I should try this
soon. Does it allow
52 matches
Mail list logo
