(Migrated) Organize Service Package

(This message has been automatically imported from the retired mailing list)

Hi,

What is the best way to organize service package?

Here is my service package

myprogram/
moduleA
moduleB
service/
zato_service.py

My understanding is we upload only zato_service to pickup dir
or we upload the whole directory to pickup dir?
If so how we can reference moduleA and B from zato service?

Thanks,
Van

On 07/04/2014 10:03 AM, Le Van wrote:

Here is my service package

myprogram/
moduleA
moduleB
service/
zato_service.py

My understanding is we upload only zato_service to pickup dir
or we upload the whole directory to pickup dir?
If so how we can reference moduleA and B from zato service?

It depends on whether moduleA and moduleB contain services or just
libraries/regular Python code.

If there are services - don’t import them directly. Always use
self.invoke(‘service.name’, {‘some’:‘input’) or if it makes sense in a
given situation, self.invoke_async instead of self.invoke

https://zato.io/docs/progguide/service-dev.html#invoke
https://zato.io/docs/progguide/service-dev.html#invoke-async

If there are libraries with common code, i.e. not body of services, and
you need to import them, they need to be placed on Python’s PYTHONPATH -
just a normal Python mechanism.

After you install Zato binaries, let’s say in /opt/zato/2.0, you’ll
notice the /opt/zato/2.0/code/zato_extra_paths directory.

https://zato.io/docs/admin/guide/installing-services.html

This is a directory that is placed on PYTHONPATH and you can keep your
modules over there, either directly or using symlinks.

Also, if you’d like for your modules to be installable from a package
index (PyPI or a private one), add them to:

  • ./code/versions.cfg
  • ./code/buildout.cfg

and then update PYTHONPATH:

$ cd ./code
$ ./bin/buildout

I agree that uploading the whole directory would be nice but
hot-deploying arbitrary Python code, because this would boil down to it,
well - it would be a major undertaking.

With time I can easily see hot-deployment be extended to cover other
things like SQLAlchemy models or config files but being able to deploy
and dynamically replace any arbitrary Python modules - that is a major
piece of work most likely requiring one to become intimately familiar
with tools like

https://pypi.python.org/pypi/guppy/0.1.10
https://launchpad.net/meliae

So this would be cool and if anyone is up to the task - let’s talk :slight_smile:

On 07/04/2014 10:03 AM, Le Van wrote:

Here is my service package

myprogram/
moduleA
moduleB
service/
zato_service.py

My understanding is we upload only zato_service to pickup dir
or we upload the whole directory to pickup dir?
If so how we can reference moduleA and B from zato service?

It depends on whether moduleA and moduleB contain services or just
libraries/regular Python code.

If there are services - don’t import them directly. Always use
self.invoke(‘service.name’, {‘some’:‘input’) or if it makes sense in a
given situation, self.invoke_async instead of self.invoke

https://zato.io/docs/progguide/service-dev.html#invoke
https://zato.io/docs/progguide/service-dev.html#invoke-async

If there are libraries with common code, i.e. not body of services, and
you need to import them, they need to be placed on Python’s PYTHONPATH -
just a normal Python mechanism.

After you install Zato binaries, let’s say in /opt/zato/2.0, you’ll
notice the /opt/zato/2.0/code/zato_extra_paths directory.

https://zato.io/docs/admin/guide/installing-services.html

This is a directory that is placed on PYTHONPATH and you can keep your
modules over there, either directly or using symlinks.

Also, if you’d like for your modules to be installable from a package
index (PyPI or a private one), add them to:

  • ./code/versions.cfg
  • ./code/buildout.cfg

and then update PYTHONPATH:

$ cd ./code
$ ./bin/buildout

I agree that uploading the whole directory would be nice but
hot-deploying arbitrary Python code, because this would boil down to it,
well - it would be a major undertaking.

With time I can easily see hot-deployment be extended to cover other
things like SQLAlchemy models or config files but being able to deploy
and dynamically replace any arbitrary Python modules - that is a major
piece of work most likely requiring one to become intimately familiar
with tools like

https://pypi.python.org/pypi/guppy/0.1.10
https://launchpad.net/meliae

So this would be cool and if anyone is up to the task - let’s talk :slight_smile:

Thank Dariusz,

Seems I have to try 2.0. Let’s give it a try.

Regards,
Van

On Fri, Jul 4, 2014 at 3:22 PM, Dariusz Suchojad dsuch@zato.io wrote:

On 07/04/2014 10:03 AM, Le Van wrote:

Here is my service package

myprogram/
moduleA
moduleB
service/
zato_service.py

My understanding is we upload only zato_service to pickup dir
or we upload the whole directory to pickup dir?
If so how we can reference moduleA and B from zato service?

It depends on whether moduleA and moduleB contain services or just
libraries/regular Python code.

If there are services - don’t import them directly. Always use
self.invoke(‘service.name’, {‘some’:‘input’) or if it makes sense in a
given situation, self.invoke_async instead of self.invoke

https://zato.io/docs/progguide/service-dev.html#invoke
https://zato.io/docs/progguide/service-dev.html#invoke-async

If there are libraries with common code, i.e. not body of services, and
you need to import them, they need to be placed on Python’s PYTHONPATH -
just a normal Python mechanism.

After you install Zato binaries, let’s say in /opt/zato/2.0, you’ll
notice the /opt/zato/2.0/code/zato_extra_paths directory.

https://zato.io/docs/admin/guide/installing-services.html

This is a directory that is placed on PYTHONPATH and you can keep your
modules over there, either directly or using symlinks.

Also, if you’d like for your modules to be installable from a package
index (PyPI or a private one), add them to:

  • ./code/versions.cfg
  • ./code/buildout.cfg

and then update PYTHONPATH:

$ cd ./code
$ ./bin/buildout

I agree that uploading the whole directory would be nice but
hot-deploying arbitrary Python code, because this would boil down to it,
well - it would be a major undertaking.

With time I can easily see hot-deployment be extended to cover other
things like SQLAlchemy models or config files but being able to deploy
and dynamically replace any arbitrary Python modules - that is a major
piece of work most likely requiring one to become intimately familiar
with tools like

https://pypi.python.org/pypi/guppy/0.1.10
https://launchpad.net/meliae

So this would be cool and if anyone is up to the task - let’s talk :slight_smile: