Pyro daemon command line

[carandraug]

We have a setup where multiple systems on the network run multiple Pyro4 Daemon servers. I would like to be able to do something like

$ pyro5-serve [MANY OPTIONS] PATH-TO-PYTHON-MODULE

and set that command-line into a systemd or windows service. Could this be in scope for Pyro?

If so, I'd be interested in working on that, together with some zeroconf to discover Pyro daemons on the network (the current pyro nameserver is not suitable for our uses because there's no centralized system that could fulfil that job).

[irmen]

Hi and thanks for your interest in Pyro5 :)

Sure, a pyro5-serve command line tool can be a useful addition to the handful of already existing tools. However there are a lot of things you can potentially configure about setting up a Pyro server. Is it feasible to have "many options" for all of these? Do you perhaps have a suggestion on how this can look like? My first thought is to only have the parameters for the Daemon.serveSimple method in there. I think you want to be able to set the logical name for each hosted object from the command line as well?

A "pyro5-serve" command line tool, is something I'd consider adding to Pyro4 as well, if it's not disruptive to any of the existing code.

About the zero-conf discovery: that would be awesome. I've tried a little bit myself but couldn't get something to work and/or didn't know what tools to use to set it up on a non-MacOS system. It would be great if this could utilize apple's zeroconf but also avahi on linux for example. We now have locate_ns() and the PYRONAME: meta protocol, I can see this being extended to locate_zc() and PYROZC: ?

[carandraug]

On 17 July 2018 at 18:18, Irmen de Jong notifications@github.com wrote:

Hi and thanks for your interest in Pyro5 :)

Sure, a pyro5-serve command line tool can be a useful addition to the handful of already existing tools. However there are a lot of things you can potentially configure about setting up a Pyro server. Is it feasible to have "many options" for all of these? Do you perhaps have a suggestion on how this can look like? My first thought is to only have the parameters for the Daemon.serveSimple method in there. I think you want to be able to set the logical name for each hosted object from the command line as well?

The main options we need are the serializer, host, and port. In addition, there would be needed an option to select which objects to serve after executing a script. More options can be added later once there's something working.

A "pyro5-serve" command line tool, is something I'd consider adding to Pyro4 as well, if it's not disruptive to any of the existing code.

I was actually going to ask about it on Pyro4 but then I noticed the note about development having been moved to Pyro5. I'd actually prefer to do this on Pyro4 since that's what we are still using. Are you willing to review my changes to implement it on Pyro4?

I'm not sure how much changes you're planning to have on Pyro5 but I'd expect that this work would be easy to port between Pyro4 and Pyro5.

Actually, if the command line options are the same, both Pyro packages could install a pyro-serve command instead of pyro4-serve and pyro5-serve.

About the zero-conf discovery: that would be awesome. I've tried a little bit myself but couldn't get something to work and/or didn't know what tools to use to set it up on a non-MacOS system. It would be great if this could utilize apple's zeroconf but also avahi on linux for example.

When I looked at this some months ago, I found that Avahi provides a separate library with an interface compatible with Apple's Bounjour.

We now have locate_ns() and the PYRONAME: meta protocol, I can see this being extended to locate_zc() and PYROZC: ?

Not sure if such interface makes sense in the context of zeroconf but I will first work on the pyro-serve and then revisit this.

Also, when that comes, the service name shold be registered at https://www.iana.org/form/ports-services (service name only). I would imagine the service name should be PYRO (not sure about having the version number on the service name).

[irmen]

The main options we need are the serializer, host, and port. In addition, there would be needed an option to select which objects to serve after executing a script. More options can be added later once there's something working.

When selecting the objects to serve, you'll also need to tell the tool what name to give them. And if you want to register them into a name server, I think, too.

Are you willing to review my changes to implement it on Pyro4?

Sure! I think it should be perfectly doable to just add this to Pyro4 without changing anything else (which is what I'm after)

I'm not sure how much changes you're planning to have on Pyro5 but I'd expect that this work would be easy to port between Pyro4 and Pyro5. Actually, if the command line options are the same, both Pyro packages could install a pyro-serve command instead of pyro4-serve and pyro5-serve.

The biggest visible changes are already in place in Pyro5 I think. General structure and components stay mostly the same so yeah. But as the user API and package itself will be different. Also to avoid possible packaging conflicts I think it's not a good idea to try to provide one overlapping command tool

I don't have experience with Zeroconf and official iana service registrations.

[irmen]

(Leaving this open as well, because I don't know if the zeroconf feature can land in Pyro4)

[irmen]

closing this - won't add zeroconf stuff or new command line tools to either Pyro4 or Pyro5

[carandraug]

won't add zeroconf stuff or new command line tools to either Pyro4 or Pyro5

Is this being rejected because we don't want zeroconf, or is it really just about not having command line tools in general? Just asking because this can be done without zeroconf (haven't done this yet because we're still stuck in Pyro4 so not much scope for me on improving Pyro5)

[irmen]

it's about the zeroconf mostly. Adding new simple command line tools is not a problem, but I won't be making them myself apart from the handful we already have right now