Daniel Nouri wrote:
First off, I think ploneenv would need to modify the runzope.bat script so
that it calls the activate script before startup.
Wouldn't it be enough to adjust the PYTHONPATH to look into the
workingenv directory first? I thought that's the only thing that's
really necessary to
Martin Aspeli wrote:
>
>
> Daniel Nouri wrote:
>
>>> This is probably a place where the buildout.cfg approach makes sense -
>>> we would be able to edit this file so that at any point in time it
>>> pointed at the right eggs to construct a Plone release. We could then
>>> let buildout run additi
Daniel Nouri wrote:
This is probably a place where the buildout.cfg approach makes sense -
we would be able to edit this file so that at any point in time it
pointed at the right eggs to construct a Plone release. We could then
let buildout run additional recipes that would e.g. run the tests an
Martin Aspeli wrote:
> Ian Bicking wrote:
>> If you use the easy_install script in the workingenv bin/, then you
>> don't have to activate the environment. Very similar to buildout,
>> workingenv scripts contain their path/environment.
>
> Right, thanks for pointing that out.
I should also menti
Hanno Schlichting wrote:
>
> Daniel Nouri wrote:
>> Hanno Schlichting wrote:
>>> Nope. Windows support for zopectl is a lot harder then just some path
>>> fiddling. But the real issue with it is not really something that is an
>>> argument for ploneout, I just took the time to implement it in it,
Daniel Nouri wrote:
> Hanno Schlichting wrote:
>> Nope. Windows support for zopectl is a lot harder then just some path
>> fiddling. But the real issue with it is not really something that is an
>> argument for ploneout, I just took the time to implement it in it, it
>> could be a separate package
Hanno Schlichting wrote:
> Nope. Windows support for zopectl is a lot harder then just some path
> fiddling. But the real issue with it is not really something that is an
> argument for ploneout, I just took the time to implement it in it, it
> could be a separate package as well. The basic problem
Martin Aspeli wrote:
> Btw, can we move at least the Plone egg to svn.plone.org? I suggest
> svn.plone.org/svn/dist/Plone or something similar, since as you pointed
> out, /Plone may be a little confusing. If this really is to become a
> "meta-egg" with just dependencies, then I think something lik
Martin Aspeli wrote:
>> I'm obviously for ploneenv/workingenv.
>
> I'm obviously a bit biased towards the buildout based approach since I
> worked on it, but I worked on it because I was never very happy with the
> way workingenv-in-instances worked. ploneenv makes that better and
> slicker, actua
Daniel Nouri wrote:
> Martin Aspeli wrote:
>
> My impression was that ploneout would at some point grow a deployment
> configuration.
Most of that is already there. It knows how to download tarballs of
Products and install them, so you can take the Plone-2.5.2 tarball as a
base, use a specific Zo
10 matches
Mail list logo