[Zope-dev] 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. ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Extending Zope2 bin/instance run
On Fri, Sep 3, 2010 at 9:50 AM, Wichert Akkerman wich...@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 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Extending Zope2 bin/instance run
On 9/3/10 10:27 , Hanno Schlichting wrote: On Fri, Sep 3, 2010 at 9:50 AM, Wichert Akkermanwich...@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. ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Extending Zope2 bin/instance run
On Fri, Sep 3, 2010 at 10:30 AM, Wichert Akkerman wich...@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 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Extending Zope2 bin/instance run
On Sep 3, 2010, at 12:50 AM, Wichert Akkerman wich...@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 davidgl...@groundwire.org 206.286.1235x32 Groundwire: You Are Connected http://groundwire.org ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] .lock files on Windows
Hi, With Plone 4 and thus Zope 2.12.10, we've noticed a problem that I think only affects Windows. Can anyone confirm or shed some more light? Basically, if we run an instance (installed via plone.recipe.zope2instance as bin\instance) in the foreground (bin\instance fg) and then kill it with Ctrl+C, the var\instance.lock and var\instance.pid files are not cleaned up. These need to be manually deleted, otherwise Zope refuses to start up with the confusing message Please stop the instance before starting it. Martin ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] .lock files on Windows
https://bugs.launchpad.net/collective.buildout/+bug/596839 Killing a fg instance with ctrl-c isn't the only scenario where the lock and pid files don't get cleaned up. On Fri, Sep 3, 2010 at 11:46 AM, Martin Aspeli optilude+li...@gmail.comoptilude%2bli...@gmail.com wrote: Hi, With Plone 4 and thus Zope 2.12.10, we've noticed a problem that I think only affects Windows. Can anyone confirm or shed some more light? Basically, if we run an instance (installed via plone.recipe.zope2instance as bin\instance) in the foreground (bin\instance fg) and then kill it with Ctrl+C, the var\instance.lock and var\instance.pid files are not cleaned up. These need to be manually deleted, otherwise Zope refuses to start up with the confusing message Please stop the instance before starting it. Martin ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope ) ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Extending Zope2 bin/instance run
-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 tsea...@palladion.com Palladion Software Excellence by Designhttp://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- ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] .lock files on Windows
On Fri, Sep 3, 2010 at 1:16 PM, Jim Pharis binbr...@gmail.com wrote: https://bugs.launchpad.net/collective.buildout/+bug/596839 Killing a fg instance with ctrl-c isn't the only scenario where the lock and pid files don't get cleaned up. I thought the problem was only the .pid file, not the .lock. Can you confirm? The .lock file should go away if the process dies in any way, but the .pid file seems to only be deleted on clean shutdown. -- Sidnei ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] .lock files on Windows
I'm on 2.13.0a3 w/plone.recipe.zope2instanec-4.0.2. Under the scenario Martin described, exiting a fg with ctrl-c, the lock file is cleaned up for me. If I kill the service using Task Manager the lock file remains. On Fri, Sep 3, 2010 at 12:33 PM, Sidnei da Silva sidnei.da.si...@canonical.com wrote: On Fri, Sep 3, 2010 at 1:16 PM, Jim Pharis binbr...@gmail.com wrote: https://bugs.launchpad.net/collective.buildout/+bug/596839 Killing a fg instance with ctrl-c isn't the only scenario where the lock and pid files don't get cleaned up. I thought the problem was only the .pid file, not the .lock. Can you confirm? The .lock file should go away if the process dies in any way, but the .pid file seems to only be deleted on clean shutdown. -- Sidnei ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] .lock files on Windows
On 3 September 2010 17:06, Jim Pharis binbr...@gmail.com wrote: I'm on 2.13.0a3 w/plone.recipe.zope2instanec-4.0.2. Under the scenario Martin described, exiting a fg with ctrl-c, the lock file is cleaned up for me. If I kill the service using Task Manager the lock file remains. It seemed to be happening intermittently. But it happened on two different PCs running Windows XP. Instances were started with bin\instance fg and killed with Ctrl+C. Martin ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Extending Zope2 bin/instance run
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 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
