[Framework-Team] Re: ploneenv - Or how using workingenv for a common Zope2 project might look like ;-)

2007-02-04 Thread Hanno Schlichting
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

[Framework-Team] Re: ploneenv - Or how using workingenv for a common Zope2 project might look like ;-)

2007-02-04 Thread Hanno Schlichting
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

[Framework-Team] Re: ploneenv - Or how using workingenv for a common Zope2 project might look like ;-)

2007-02-04 Thread Daniel Nouri
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

[Framework-Team] Re: ploneenv - Or how using workingenv for a common Zope2 project might look like ;-)

2007-02-04 Thread Daniel Nouri
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

[Framework-Team] Re: ploneenv - Or how using workingenv for a common Zope2 project might look like ;-)

2007-02-04 Thread Hanno Schlichting
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

[Framework-Team] Re: ploneenv - Or how using workingenv for a common Zope2 project might look like ;-)

2007-02-04 Thread Daniel Nouri
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,

[Framework-Team] Re: ploneenv - Or how using workingenv for a common Zope2 project might look like ;-)

2007-02-04 Thread Daniel Nouri
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

[Framework-Team] Re: ploneenv - Or how using workingenv for a common Zope2 project might look like ;-)

2007-02-04 Thread Martin Aspeli
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

[Framework-Team] Re: ploneenv - Or how using workingenv for a common Zope2 project might look like ;-)

2007-02-04 Thread Daniel Nouri
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

[Framework-Team] Re: ploneenv - Or how using workingenv for a common Zope2 project might look like ;-)

2007-02-04 Thread Ian Bicking
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