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
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
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
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
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
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,
12 matches
Mail list logo
