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 Zope release tarball and use specific versions of some eggs and build you a Zope instance with all those things in it. That's at least the basic requirements I see for a deployment. > I've been working with buildout before[2], but I still find it hard to use > (not as someone who only executes bin/buildout obviously, but as someone > trying to make a testrunner script, for example). I'm not sure if the testrunner is the real problem here ;) I managed to adjust the zopectl test command in my instance script, so it does work for all eggs and products. But it's rather hacky and I would much prefer if this wouldn't be necessary in the first place. >> - It works in Windows. :) I have no idea how hard it's to make ploneenv >> work on Windows, but I hope it's not too bad. The scripts Hanno wrote do >> give us a near-proper zopectl for Windows as well, which is nice. I >> imagine these could be adapted to be used with plain Zope instances, >> though. I assume workingenv gives us setuptools script support locally >> as well. > > Support for Windows should be fairly trivial. I would appreciate it if > someone (Hanno?) gave it a try. Basically, all we need is the correct way > to patch bin/zopectl so that it runs the bin/activate.bat script before > startup. We shouldn't seriously consider "runs on Windows" as an argument > for ploneout, just because ploneenv hasn't seen a Windows developer yet. :-) 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 with it is, that it relies on Unix-specific thread handling for the start/stop/restart/debug/status options, but it calls the internal status command at every start of the script, so on Windows it fails before you can do anything with it. I adjusted the internal status handling, so it doesn't look for the Unix specific stuff but should look if a Windows service of the instance is installed and running. Ideally this could move into Zope itself. I have seen that somebody implemented something alike for instancemanager... Hanno _______________________________________________ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
