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 Zope
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 ins
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 work
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 both
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 w
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
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
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 thi
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 r
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 wo
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.
- 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 code
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,
b
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
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 "o
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 superfluou
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 whethe
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
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 w
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 with
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"
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:
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 pat
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 t
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 o
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
oth
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
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
-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
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 be
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 t
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 oth
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 repeatable
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 t
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 buildout
Ian Bicking wrote:
After setting that project aside someone else at TOPP (Luke Tucker)
did a buildout for Deliverance because we needed to build some
non-Python libraries and that was a feature of buildout; that did end up
working eventually (after considerable effort), but it was not a very
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
unres
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:
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
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
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 gene
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 buildout,
On 25 Jan 2007, at 23:13 , whit 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
(sorry if this ends up going out twice, I'm trying to figure out this
gmane thing and apparently I hadn't figured this out when I first sent it)
Whit pointed me to this thread. I won't reply to specifics here, but
maybe just describe what we're doing (and planning to do), and how
workingenv d
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 differe
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
de
Whit pointed me to this thread. 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.
So... recently we (The Open Planning Project -- more specifically Rob
Miller) decided we need a better way to deploy our specifi
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
** N
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
de
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
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 Zop
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 Zop
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 Zope 2 community
Right. What I'm saying is that this should be the default. Sensible
defaults is sometimes all it takes to get something adopted. Just
look at that Plone thang ;).
Yeah. I'd be happy to move the Data.fs directory to var/${part_name}
under the main buildout directory.
I'd also be happy to ma
On 23 Jan 2007, at 23:56 , 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 bene
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 Zope 2 community.
I believe this is
Martin Aspeli wrote:
I've been playing with this a bit over the past couple of days, and it's
now in a state where I understand what's going on and I feel that I may
well try to use it in a real project. It still needs a bit of work
(notably, the testrunner is struggling to run tests for things
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
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 http://www
Hi,
sorry, I'm catching up with my mail slowly these days...
Martijn Faassen wrote:
> Hey,
>
> Martin Aspeli wrote:
>> Martijn Faassen wrote:
>
>>> If you used a pure buildout solution you'd have gotten an ImportError on
>>> elementtree that you'd need to fix by altering a setup.py somewhere.
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 h
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 easy_i
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 mi
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 easy_i
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 easy_install to be used as wel
65 matches
Mail list logo