[Framework-Team] Re: ploneenv - Or how using workingenv for a common Zope2 project might look like ;-)
Well, yes, but if one developer does edit buildout.cfg (we added a new requirement or a new step in the build process), everyone else svn up's that file and runs bin/buildout and their environments are the same again. The --requirements file is, as far as I understand, a one-off bootstrap. the only difference between buildout.cfg and a -r file that I see is you can specify builds of non-python based products in a buildout.cfg. Either can live in an svn repo and be updated. -r files can be combined with links pages and used as a sort of external way to manage distribution; requirements file let you specify what to install as a development egg(similar to buildout), why changing the links page will actually change what code is checked out as a development egg. In the case of building zope and plone, I don't think there is much advantage one way or another; most of the dependencies could be or should be eggs(and I think this should be the emphasis rather than forcing workingenv or buildout down anybodies throat). If eggs work, you can use what you like; making a zc.buildout recipe to read requirements file would be pretty easy(see this script: https://svn.openplans.org/svn/PoachEggs/trunk/). The situation changes case when looking at things like building a real Plone deployment setup: squid, pound, nginx, postfix for listen, etc. The little bit of work I've down with trying to split deployment and dev builds is that having the option to run just some of the build is really nice(either through options on a script or multiple scripts). It also eliminates a bit of the fear factor that comes from installing a monolith. -w -- -- d. whit morriss -- - senior engineer, opencore - - http://www.openplans.org - - m: 415-710-8975 - If you don't know where you are, you don't know anything at all Dr. Edgar Spencer, Ph.D., 1995 ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: ploneenv - Or how using workingenv for a common Zope2 project might look like ;-)
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, actually, and I quite like it. I'm not really for or against anything here. My main reason to work on ploneout has been that our current general approach of handling eggs in Zope instances (which is not to use them at all, but use a plone3-libs bundle) annoyed me, especially since I saw that Whit already had some nice code in wicked relying on entry-points but had to remove it again, as we have no advertised way that makes it easy to setup an instance with properly installed eggs. As I already knew how to handle workingenv, I thought I'd bring zc.buildout to the table and realized that we would only be able to discuss about it for real, if it would be able to actually build us a working Plone 3 environment, hence ploneout was born... One reason why I like ploneout is that my MacBook's monitor is partially damaged and I'll have to live without it for some weeks once I send it into repair. For those weeks I'll use a different (Windows) machine at work and need a way to get my development environment up and running, preferably in the same way I'm already used to and would prefer it not having to spent too much time on it. I'd guess this is not a good argument in general ;) Ultimately, I think we are arguing preferences and taste. The main lever for all of this is eggs (which we all love, of course :-)) and both approaches basically depend on eggs and setuptools as much as possible. Yep, for instance I never liked the way a Zope instance currently looks like and so in return have no problems to get used to a different layout, others may have different preferences here. After all I think we are making very good progress in exploring different kinds of setting up our development environments. The one thing we can probably agree on, is that we need something better than the current plone3-libs bundle ;) Hanno ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: ploneenv - Or how using workingenv for a common Zope2 project might look like ;-)
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 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... I looked at the Zope 2 recipe briefly and thought it only fiddlest with PYTHONPATH in bin/runzope.bat. I don't really understand the other issue with Unix specific threading that you mention. First off, I think ploneenv would need to modify the runzope.bat script so that it calls the activate script before startup. Daniel ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: ploneenv - Or how using workingenv for a common Zope2 project might look like ;-)
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 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... I looked at the Zope 2 recipe briefly and thought it only fiddlest with PYTHONPATH in bin/runzope.bat. I don't really understand the other issue with Unix specific threading that you mention. Lucky you, basically the current state is: zopectl doesn't work on Windows! But I found out that it's not that hard to enhance it in a way so it does work on Windows... all you need to do is to look into the internals of zopectl and zdaemon combined with how configuration files are parsed at Zope startup... and add some platform specific conditional code. Now after a refreshing my memory it fails on socket handling in zdctl.py in zdaemon on the line (sock = socket.socket(socket.AF_UNIX, socket.SOCK_STREAM)) where socket.AF_UNIX is not defined on Windows. Basically the way Zope is started in non-foreground mode on Unix is different from Windows, where you need to install a service which you can start/stop/restart... 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 activate a workingenv? Hanno ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: ploneenv - Or how using workingenv for a common Zope2 project might look like ;-)
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, 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... I looked at the Zope 2 recipe briefly and thought it only fiddlest with PYTHONPATH in bin/runzope.bat. I don't really understand the other issue with Unix specific threading that you mention. Lucky you, basically the current state is: zopectl doesn't work on Windows! But I found out that it's not that hard to enhance it in a way so it does work on Windows... all you need to do is to look into the internals of zopectl and zdaemon combined with how configuration files are parsed at Zope startup... and add some platform specific conditional code. Now after a refreshing my memory it fails on socket handling in zdctl.py in zdaemon on the line (sock = socket.socket(socket.AF_UNIX, socket.SOCK_STREAM)) where socket.AF_UNIX is not defined on Windows. Basically the way Zope is started in non-foreground mode on Unix is different from Windows, where you need to install a service which you can start/stop/restart... I see. So that's a bug in Zope 2's Windows compatibility? Is there a tracker issue for this? 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 activate a workingenv? Calling the activate script (on Windows) and including it (on Unix) is the way to activate a workingenv. Internally, activate does more or less what you say, but I never had to worry about that. Daniel ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: ploneenv - Or how using workingenv for a common Zope2 project might look like ;-)
I'm obviously for ploneenv/workingenv. I wouldn't have developed ploneenv
otherwise. So here is my pro-ploneenv reactions.
Martin Aspeli wrote:
First of all, I think this is great. :) The important thing here is that
people can use what they feel comfortable with - at the end of the day,
all the actual software should become eggs that we can share.
However, I'd like to try and clarify what I see as some of the
philosophical differences between ploneout and ploneenv. Hopefully, this
is useful to people.
I honestly don't think it's a fair criticism of zc.buildout-based
solutions that they are more heavyweight or complex (not that Daniel has
said that, but it seems to be a fairly common sentiment). The only hard
things for me when I started to work with zc.buildout to help Hanno
complete ploneout were (a) getting over my initial fear of something new
with a scary name and (b) understanding setuptools and eggs in general.
The whole of zc.buildout + ploneout's specific recipes (more on that
later) is probably a bit bigger than workingenv + ploneenv, but not by
an order of magnitude or anything like that. Most of the code is fairly
trivial plain python.
I believe that the whole of zc.buildout and ploneout is *a lot* bigger
compared to workingenv and ploneenv in lines of code. Unless you mean to
compare the buildout *recipes only* with both workingenv and ploneenv, which
seems unfair. For the reasons of compactness and transparency, I expect
ploneenv to be more maintainable.
Anyway, the main reason I think that workingenv is simpler is because it's
transparent to the user. By user I mean someone who has used distutils
before (i.e. python setup.py install) and someone who wants who has done
Zope instances before and wants to reapply his experience.
ploneenv is easier for developers because it lets them use Zope instances
the way they're used to use them. That is, bin/zopectl works, Products/
works as expected etc. And there is no way that workingenv could decide to
delete any directory, which you might consider a pitfall with ploneout.
Now, I suspect ploneenv and ploneout are not equivalent. ploneenv gives
you a new Zope instance which you can use for your own development or
deployment. ploneout is aimed squarely at core Plone developers, because
it configures all of Plone's eggs as development eggs and does something
similar for its products.
My impression was that ploneout would at some point grow a deployment
configuration.
So, let's instead compare ploneenv with the PasteScript template I've
been making that lets you create a new buildout for your own project.
This uses the same recipes as ploneout in order to create a Zope
instance (and more), but considers Plone as a dependency to be managed
by buildout. Let's also assume that the Plone egg that Daniel mentions
exists, and that it takes care of all the products. For comparison's
sake, let's also say that you want to use an existing Zope (2.10.2)
installation rather than let zc.buldout download, compile and configure
it for you.
BTW, the Plone egg *does* exist[1]. And I'd like to move it to
svn.plone.org :-)
$ paster create -t plone3_buildout myproject zope2_install=~/zope2.10
This creates buildout_test/buildout.cfg after asking a few questions
(about Zope username/password, port, development mode, verbose
security). Here's minimal version (using the fabled Plone egg, and you
get a bit more documentation in comments when you do it for real):
[buildout]
parts = instance
eggs = Plone
[instance]
recipe = z2c.recipe.zope2instance
zope2-location = ~/zope2.10
user = admin:admin
eggs = ${buildout:eggs}
You then run (once):
$ python bootstrap.py
And then (each time you change buildout.cfg):
$ bin/buildout
zc.buildout is basically just a command runner. It makes it easy to pass
stuff around in options between the different sections of
buildout.cfg. These options are used by various recipes (eggs with
commands that buildout finds using entry points). For ploneout, Hanno
and I wrote a couple of recipes, the most important one being
z2c.recipe.zope2instance, which can create and configure a zope 2
instance. To do so, it needs to know where to find Zope, the root user,
and which eggs you want Zope to know about (here referring back to the
global list of eggs in the [buildout] section).
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).
Because Zope 2 isn't terribly good with eggs, the recipe uses
zc.buildout's fairly sophisticated egg support to tell Zope exactly
which eggs you want it to know about (in this case, that's just the
Plone egg, and all its dependencies, i.e. all of Plone). Hanno also made
use of this recipe to create a wrapper around 'zopectl' that (a) works
on Windows and (b)
