Extending Zope2 bin/instance run
I have noticed that now that we are almost exclusively using eggs to distribute our software using "bin/instance run" has become difficult: often the script you want to run is located inside an egg which makes to path to it hard to predict. This is not the most user friendly command: bin/instance run eggs/my.package-*/my/package/script.py If a user is using a shared egg directory from zc.buildout or something else the egg can be anywhere on the filesystem, making it next to impossible to explain to users. I am considering to modify bin/instance run to check if its first argument is a filesystem path, and if not consider the argument to be a dotted name of a callable which should be invoke. That way backwards compatibility remains, but you can now also do this: bin/instance run my.package.script.main I am not sure if this is best done in plone.recipe.zope2instance or Zope2.Startup.zopectl. They have differing versions of ZopeCmd. Perhaps the plone.recipe.zope2instance code should be merged into Zope2's original as well? Wichert.
On Fri, Sep 3, 2010 at 9:50 AM, Wichert Akkerman <wichert@wiggy.net> wrote:
I have noticed that now that we are almost exclusively using eggs to distribute our software using "bin/instance run" has become difficult: often the script you want to run is located inside an egg which makes to path to it hard to predict. This is not the most user friendly command:
bin/instance run eggs/my.package-*/my/package/script.py
You could also expose your script as a console_script and thus get it into bin/.
I am considering to modify bin/instance run to check if its first argument is a filesystem path, and if not consider the argument to be a dotted name of a callable which should be invoke. That way backwards compatibility remains, but you can now also do this:
bin/instance run my.package.script.main
I don't see any reason why we shouldn't do this.
I am not sure if this is best done in plone.recipe.zope2instance or Zope2.Startup.zopectl. They have differing versions of ZopeCmd. Perhaps the plone.recipe.zope2instance code should be merged into Zope2's original as well?
The code in the zope2instance recipe has diverged both in implementation and semantics from the original Zope2 code. I tried to push back some of that in 2.11 while porting the Windows service support code over. But there's again a lot of other changes. Given that this code is completely untested except for people actually using it on different platforms I'm not personally going to merge the codebase any further. But anyone else is free to do so given they test the modified code under all supported platforms and especially Windows. Hanno
On 9/3/10 10:27 , Hanno Schlichting wrote:
On Fri, Sep 3, 2010 at 9:50 AM, Wichert Akkerman<wichert@wiggy.net> wrote:
I have noticed that now that we are almost exclusively using eggs to distribute our software using "bin/instance run" has become difficult: often the script you want to run is located inside an egg which makes to path to it hard to predict. This is not the most user friendly command:
bin/instance run eggs/my.package-*/my/package/script.py
You could also expose your script as a console_script and thus get it into bin/.
But then I'ld have to figure out where the zope2.conf is and run all the undocumented Zope startup magic, all of which bin/instance gets for free.
I am considering to modify bin/instance run to check if its first argument is a filesystem path, and if not consider the argument to be a dotted name of a callable which should be invoke. That way backwards compatibility remains, but you can now also do this:
bin/instance run my.package.script.main
I don't see any reason why we shouldn't do this.
Ok.
I am not sure if this is best done in plone.recipe.zope2instance or Zope2.Startup.zopectl. They have differing versions of ZopeCmd. Perhaps the plone.recipe.zope2instance code should be merged into Zope2's original as well?
The code in the zope2instance recipe has diverged both in implementation and semantics from the original Zope2 code. I tried to push back some of that in 2.11 while porting the Windows service support code over. But there's again a lot of other changes.
Given that this code is completely untested except for people actually using it on different platforms I'm not personally going to merge the codebase any further. But anyone else is free to do so given they test the modified code under all supported platforms and especially Windows.
I can't test under Windows, so how can we proceed to make any changes at all there? Wichert.
On Fri, Sep 3, 2010 at 10:30 AM, Wichert Akkerman <wichert@wiggy.net> wrote:
On 9/3/10 10:27 , Hanno Schlichting wrote:
Given that this code is completely untested except for people actually using it on different platforms I'm not personally going to merge the codebase any further. But anyone else is free to do so given they test the modified code under all supported platforms and especially Windows.
I can't test under Windows, so how can we proceed to make any changes at all there?
If your code doesn't touch the start/stop/fg/status code, I'll trust you to code things properly. I'm only concerned about the startup code and the various ways in which return codes, process forks vs. subprocesses and file locks needs to be handled there. Hanno
On Sep 3, 2010, at 12:50 AM, "Wichert Akkerman" <wichert@wiggy.net> wrote:
I have noticed that now that we are almost exclusively using eggs to distribute our software using "bin/instance run" has become difficult: often the script you want to run is located inside an egg which makes to path to it hard to predict. This is not the most user friendly command:
bin/instance run eggs/my.package-*/my/package/script.py
If a user is using a shared egg directory from zc.buildout or something else the egg can be anywhere on the filesystem, making it next to impossible to explain to users.
I am considering to modify bin/instance run to check if its first argument is a filesystem path, and if not consider the argument to be a dotted name of a callable which should be invoke. That way backwards compatibility remains, but you can now also do this:
bin/instance run my.package.script.main
I am not sure if this is best done in plone.recipe.zope2instance or Zope2.Startup.zopectl. They have differing versions of ZopeCmd. Perhaps the plone.recipe.zope2instance code should be merged into Zope2's original as well?
At some point I made it possible to add additional bin/instance commands via a plone.recipe.zope2instance entry point. ---------- David Glick Web Developer davidglick@groundwire.org 206.286.1235x32 Groundwire: You Are Connected http://groundwire.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Wichert Akkerman wrote:
I have noticed that now that we are almost exclusively using eggs to distribute our software using "bin/instance run" has become difficult: often the script you want to run is located inside an egg which makes to path to it hard to predict. This is not the most user friendly command:
bin/instance run eggs/my.package-*/my/package/script.py
If a user is using a shared egg directory from zc.buildout or something else the egg can be anywhere on the filesystem, making it next to impossible to explain to users.
I am considering to modify bin/instance run to check if its first argument is a filesystem path, and if not consider the argument to be a dotted name of a callable which should be invoke. That way backwards compatibility remains, but you can now also do this:
bin/instance run my.package.script.main
What about using something like the EntryPoint syntax: $ bin/instance run my.package.script:main We could even add a new entry point class for it, and allow: $ bin/instance run egg:my.package#some_name
I am not sure if this is best done in plone.recipe.zope2instance or Zope2.Startup.zopectl. They have differing versions of ZopeCmd. Perhaps the plone.recipe.zope2instance code should be merged into Zope2's original as well?
I don't know anything about the code in plone.recipe.zope2instance. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkyBIHQACgkQ+gerLs4ltQ5v1wCfcnSHwVEQ76SmlftN716mc7t3 C7IAoJHxDMrH/LW1WO40k1pFXC5RP0su =Hrl+ -----END PGP SIGNATURE-----
On 03/09/2010 17:21, Tres Seaver wrote:
I am not sure if this is best done in plone.recipe.zope2instance or Zope2.Startup.zopectl. They have differing versions of ZopeCmd. Perhaps the plone.recipe.zope2instance code should be merged into Zope2's original as well?
I don't know anything about the code in plone.recipe.zope2instance.
Yes, and please remember that Plone is not the only consumer of Zope 2, and neither is plone.recipe.zope2instance the only way to deploy Zope... Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk
On 2010-9-4 00:43, Chris Withers wrote:
On 03/09/2010 17:21, Tres Seaver wrote:
I am not sure if this is best done in plone.recipe.zope2instance or Zope2.Startup.zopectl. They have differing versions of ZopeCmd. Perhaps the plone.recipe.zope2instance code should be merged into Zope2's original as well?
I don't know anything about the code in plone.recipe.zope2instance.
Yes, and please remember that Plone is not the only consumer of Zope 2, and neither is plone.recipe.zope2instance the only way to deploy Zope...
there is absolutely nothing Plone-specific about plone, and people are using it for non-Plone systems as well. Wichert. -- Wichert Akkerman <wichert@wiggy.net> It is simple to make things. http://www.wiggy.net/ It is hard to make things simple.
On 2010-9-5 16:03, Wichert Akkerman wrote:
On 2010-9-4 00:43, Chris Withers wrote:
On 03/09/2010 17:21, Tres Seaver wrote:
I am not sure if this is best done in plone.recipe.zope2instance or Zope2.Startup.zopectl. They have differing versions of ZopeCmd. Perhaps the plone.recipe.zope2instance code should be merged into Zope2's original as well?
I don't know anything about the code in plone.recipe.zope2instance.
Yes, and please remember that Plone is not the only consumer of Zope 2, and neither is plone.recipe.zope2instance the only way to deploy Zope...
there is absolutely nothing Plone-specific about plone, and people are using it for non-Plone systems as well.
.. about plone.recipe.zope2instance that is. Obviously Plone itself is quite Plone-specific :) Wichert. -- Wichert Akkerman <wichert@wiggy.net> It is simple to make things. http://www.wiggy.net/ It is hard to make things simple.
On 05/09/2010 15:03, Wichert Akkerman wrote:
On 2010-9-4 00:43, Chris Withers wrote:
On 03/09/2010 17:21, Tres Seaver wrote:
I am not sure if this is best done in plone.recipe.zope2instance or Zope2.Startup.zopectl. They have differing versions of ZopeCmd. Perhaps the plone.recipe.zope2instance code should be merged into Zope2's original as well?
I don't know anything about the code in plone.recipe.zope2instance.
Yes, and please remember that Plone is not the only consumer of Zope 2, and neither is plone.recipe.zope2instance the only way to deploy Zope...
there is absolutely nothing Plone-specific about plone, and people are using it for non-Plone systems as well.
It's an overly verbose throwback to before Zope2 was a properly packaged package ;-) I prefer zope2instance, or just using a raw buildout with one of the templating recipes for your zope.conf, but then I would say that... Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk
On 9/3/10 18:21 , Tres Seaver wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Wichert Akkerman wrote:
I have noticed that now that we are almost exclusively using eggs to distribute our software using "bin/instance run" has become difficult: often the script you want to run is located inside an egg which makes to path to it hard to predict. This is not the most user friendly command:
bin/instance run eggs/my.package-*/my/package/script.py
If a user is using a shared egg directory from zc.buildout or something else the egg can be anywhere on the filesystem, making it next to impossible to explain to users.
I am considering to modify bin/instance run to check if its first argument is a filesystem path, and if not consider the argument to be a dotted name of a callable which should be invoke. That way backwards compatibility remains, but you can now also do this:
bin/instance run my.package.script.main
What about using something like the EntryPoint syntax:
$ bin/instance run my.package.script:main
We could even add a new entry point class for it, and allow:
$ bin/instance run egg:my.package#some_name
I've opted for a third alternative: use an entry point to define the extra commands. If you do this in setup.py: entry_points=""" [zopectl.command] mycommand = mypackage.commands:func """ you can do: $ bin/instance mycommand [<args>] The advantage of this approach is that it makes for more user friendly commands that do not needlessly expose implementation details to the commandline. Wichert.
On Thu, Sep 09, 2010 at 02:45:10PM +0200, Wichert Akkerman wrote:
I've opted for a third alternative: use an entry point to define the extra commands. If you do this in setup.py:
entry_points=""" [zopectl.command] mycommand = mypackage.commands:func """
you can do:
$ bin/instance mycommand [<args>]
The advantage of this approach is that it makes for more user friendly commands that do not needlessly expose implementation details to the commandline.
I like this. Marius Gedminas -- http://pov.lt/ -- Zope 3/BlueBream consulting and development
participants (6)
-
Chris Withers -
David Glick -
Hanno Schlichting -
Marius Gedminas -
Tres Seaver -
Wichert Akkerman