(This message has been automatically imported from the retired mailing list)
Hello,
My name is Amit and I’ve been trying for the past few weeks to be able to
get zato into a pip ready state so someone could just pip install zato.
I am not sure as to how mailing lists work so dropping in a first message
to introduce myself.
On 06/19/2014 06:26 AM, Amit Prakash Ambasta wrote:
My name is Amit and I’ve been trying for the past few weeks to be able to
get zato into a pip ready state so someone could just pip install zato.I am not sure as to how mailing lists work so dropping in a first message
to introduce myself.
Hello Amit,
as we have started to talk about it off-list, here are my thoughts on
the idea.
First thing is, it’s great that you’d like to help out 
It’s really
great to see such an enthusiasm!
When thinking of any sort of installers, please always keep in mind that:
pip and PyPI are for installing Python modules and packages Zato is
not a simple Python module nor package.
The point above is really important - pip merely installs Python
modules. It’s very good at it and that’s it. Zato is a programming
platform that is written in Python but it doesn’t mean it has to be
installable using a tool that has recently become popular.
The point on recent popularity is an important one - over years we
have had easy_install, distribute, distribute2, pip, project forks,
merges, splits and joins - personally I’ve spent enough time on it all
and /perhaps/ now that pip is in Python 3.x things will settle down.
I really wish everyone involved in developing Python packaging story all
the best and I really hope things will be clearer now. But I’ve been
using Python since 2.1 and it’s way too early for me to categorically
say pip is the way to go. I need more time to get convinced.
In that regards, consider Zato similar to PostgreSQL. The latter being
built using a Makefile but it doesn’t mean one should be able to do
stuff like ‘make download postgresql’.
Up until recently, the only Python packaging tool almost capable of
producing result Zato needs was buildout. Some time ago conda has come
around and perhaps conda is something to look at but I’m 100% pip right
won’t handle what we need. Perhaps with time but not now.
Like I say, I hope and keep fingers crossed Python’s packaging situation
but there are no packaging problems in Zato that pip solves.
In fact, given it’s never been meant to support what Zato needs, I’m
certain it won’t do. But this is because there are certain goals for
Zato installers outside of pip’s scope, not that because pip doesn’t
live up to its own promises.
Actually - if you have a look at the very first commit to GH …
https://github.com/zatosource/zato/blob/41476e8c27d0eb309f45762015fbcdc09de8547f/code/install.sh
https://github.com/zatosource/zato/blob/41476e8c27d0eb309f45762015fbcdc09de8547f/code/buildout.cfg
… you’ll already notice that pip will not:
This was 2 years ago and this is how it looks like today
https://github.com/zatosource/zato/blob/master/code/_install-deb.sh
https://github.com/zatosource/zato/blob/master/code/_install-fedora.sh
And it’s all OK - pip simply is not meant for things we need. There’s no
need to use this particular tool if we have a toolbox full of other options.
That is, given a bare OS when one does ‘yum install zato’ or ‘apt-get
install zato’ or simply install it from source, it should always install
the same set of packages given the same version of the OS.
Builds must always be reproducible, this is a topmost priority. Please
remember that people, me including, support production systems that
aren’t operated by Python programmers and everyone should always have
the same environment given the same build process.
If I have a local VM of Ubuntu 12.04.3 LTS up to do date and a Zato user
has the same system then ‘apt-get install zato’ always produces the same
output. There simply can be no exceptions to that process.
That point rules out providing dependencies in the form of ‘foo>=1.23’.
These always need to explicitly listed. And conversely, there can be no
dependencies that are not listed in a given requirements file (pip or
buildout).
But even in such a simple project as apitest I immediately hit upon a
feature pip doesn’t support - that of warning when a dependency of a
package attempts to install its own dependency I didn’t explicitly list
in requirements.txt.
And Zato must support use cases on a order of magnitude harder, like
making sure Python 2.7 is available in the first place and links to
correct system libraries. Or that HAProxy is there.
These are real requirements set before a packaging tool and pip doesn’t
deal with them, it’s all simply outside of its scope, at least for now.
I honestly am very thankful for your work, it’s terrific to see such a
passion but at that point I’m not convinced pip is something we really,
really need.
If you’d still like to work on it, I’d be happy to discuss it with you
here on the list and make sure your works go in the same direction the
rest of the project but right now I just can’t see any issue pip solves
for us.
This is open-source so hey, you can do anything you want but there
are some tickets waiting in the tracker and perhaps you’d rather be
interested in picking up one of these instead?
These are all the tickets that need to be closed before we can cut the
2.0 release. If you’d like to get involved in the project, maybe you
could have a look at them and say a bit about what you’re interested in
generally as Python development goes so that I could suggest a ticket
that you’d find a worthwhile goal or perhaps we’d open a new one for you?
What do you think?
On 06/19/2014 06:26 AM, Amit Prakash Ambasta wrote:
My name is Amit and I’ve been trying for the past few weeks to be able to
get zato into a pip ready state so someone could just pip install zato.I am not sure as to how mailing lists work so dropping in a first message
to introduce myself.
Hello Amit,
as we have started to talk about it off-list, here are my thoughts on
the idea.
First thing is, it’s great that you’d like to help out It’s really
great to see such an enthusiasm!
When thinking of any sort of installers, please always keep in mind that:
pip and PyPI are for installing Python modules and packages Zato is
not a simple Python module nor package.
The point above is really important - pip merely installs Python
modules. It’s very good at it and that’s it. Zato is a programming
platform that is written in Python but it doesn’t mean it has to be
installable using a tool that has recently become popular.
The point on recent popularity is an important one - over years we
have had easy_install, distribute, distribute2, pip, project forks,
merges, splits and joins - personally I’ve spent enough time on it all
and /perhaps/ now that pip is in Python 3.x things will settle down.
I really wish everyone involved in developing Python packaging story all
the best and I really hope things will be clearer now. But I’ve been
using Python since 2.1 and it’s way too early for me to categorically
say pip is the way to go. I need more time to get convinced.
In that regards, consider Zato similar to PostgreSQL. The latter being
built using a Makefile but it doesn’t mean one should be able to do
stuff like ‘make download postgresql’.
Up until recently, the only Python packaging tool almost capable of
producing result Zato needs was buildout. Some time ago conda has come
around and perhaps conda is something to look at but I’m 100% pip right
won’t handle what we need. Perhaps with time but not now.
Like I say, I hope and keep fingers crossed Python’s packaging situation
but there are no packaging problems in Zato that pip solves.
In fact, given it’s never been meant to support what Zato needs, I’m
certain it won’t do. But this is because there are certain goals for
Zato installers outside of pip’s scope, not that because pip doesn’t
live up to its own promises.
Actually - if you have a look at the very first commit to GH …
https://github.com/zatosource/zato/blob/41476e8c27d0eb309f45762015fbcdc09de8547f/code/install.sh
https://github.com/zatosource/zato/blob/41476e8c27d0eb309f45762015fbcdc09de8547f/code/buildout.cfg
… you’ll already notice that pip will not:
This was 2 years ago and this is how it looks like today
https://github.com/zatosource/zato/blob/master/code/_install-deb.sh
https://github.com/zatosource/zato/blob/master/code/_install-fedora.sh
And it’s all OK - pip simply is not meant for things we need. There’s no
need to use this particular tool if we have a toolbox full of other options.
That is, given a bare OS when one does ‘yum install zato’ or ‘apt-get
install zato’ or simply install it from source, it should always install
the same set of packages given the same version of the OS.
Builds must always be reproducible, this is a topmost priority. Please
remember that people, me including, support production systems that
aren’t operated by Python programmers and everyone should always have
the same environment given the same build process.
If I have a local VM of Ubuntu 12.04.3 LTS up to do date and a Zato user
has the same system then ‘apt-get install zato’ always produces the same
output. There simply can be no exceptions to that process.
That point rules out providing dependencies in the form of ‘foo>=1.23’.
These always need to explicitly listed. And conversely, there can be no
dependencies that are not listed in a given requirements file (pip or
buildout).
But even in such a simple project as apitest I immediately hit upon a
feature pip doesn’t support - that of warning when a dependency of a
package attempts to install its own dependency I didn’t explicitly list
in requirements.txt.
And Zato must support use cases on a order of magnitude harder, like
making sure Python 2.7 is available in the first place and links to
correct system libraries. Or that HAProxy is there.
These are real requirements set before a packaging tool and pip doesn’t
deal with them, it’s all simply outside of its scope, at least for now.
I honestly am very thankful for your work, it’s terrific to see such a
passion but at that point I’m not convinced pip is something we really,
really need.
If you’d still like to work on it, I’d be happy to discuss it with you
here on the list and make sure your works go in the same direction the
rest of the project but right now I just can’t see any issue pip solves
for us.
This is open-source so hey, you can do anything you want but there
are some tickets waiting in the tracker and perhaps you’d rather be
interested in picking up one of these instead?
These are all the tickets that need to be closed before we can cut the
2.0 release. If you’d like to get involved in the project, maybe you
could have a look at them and say a bit about what you’re interested in
generally as Python development goes so that I could suggest a ticket
that you’d find a worthwhile goal or perhaps we’d open a new one for you?
What do you think?
Just a question, is there any sort of documentation our install script for
installing zato from source separate from using debian packages? Is there
a buildout script? I know for me, pip isn’t as big a deal. But being able
to run something in a virtualenv is nice to keep things isolated rather
than going for a full-blown VM.
On Mon, Jun 23, 2014 at 4:57 PM, Amit Prakash Ambasta <
amit.prakash.ambasta@gmail.com> wrote:
Hi Darius
I understand your concerns and accept the fact that pip is not the ideal
tool for zato as a commercial ESB. I’ve stayed with pip mostly due to my
personal requirements[ I run gentoo ] and an interest in python packaging.
I understand the issues you’ve mentioned and pip would indeed not address a
lot of issues which you mentioned above. Hence as far as the packaging bits
go, I make only minor changes to upstream and have forked it for internal
consumption.At some point I’ll try splitting the setup into zato-installer and pip
packages strictly as a matter of interest and experimentation. I have
primarily been a django developer for the past few years so I am still
trying to wrap my head around how zato works. I hope to be able to
contribute to the issues wrt 2.0 at some point in the short future.On Tue, Jun 24, 2014 at 2:05 AM, Dariusz Suchojad dsuch@zato.io wrote:
On 06/23/2014 10:18 PM, Amit Prakash Ambasta wrote:
Would it be possible to discuss the same over a github issue?
Sure, naturally.
Just please keep in mind that pip is not the right tool for the job. Pip
not only solves none of the project’s needs but actually re-introduces a
point of failure we’ve recently dealt with.So I would feel very, very bad if I didn’t warn you each time pip’s
usage was suggestedI’ll present you wit a story - a couple of days ago I was working with a
client on a screen share, setting up a new environment as we spoke online.Embarrassingly enough, I could not install Zato from source because
twice in a row Internet connectivity issues prevented the OS I was doing
it on to download things from PyPI.Obviously, it’s no one’s fault really - but can you imagine how bad it
looks when you do such things live?Speaking broadly - so far I installed Zato from source some 200-250
times, say. Out of it, about 10-15% the installation failed because a
dependency could not be downloaded, because a site was down, another one
was undergoing maintenance or an author of a package removed the package
altogether.Perhaps such things are not visible when a project has 10 dependencies
but Zato has 100+ of them.I simply cannot agree to anything like that anymore - hence a great deal
of, and I really mean a lot, effort goes into preparing various build
scripts for Debian/Ubuntu/RHEL/CentOS/SLES.That way packages for 1.1 are precompiled and no one needs to go through
any pains at all. For others, there’s the ability to prepare their own
packages.So just to repeat it - using pip would be a step back. It doesn’t solve
anything and would require bending it to fulfill what we need. There’s
simply no need for it.And I just cannot agree to it simply because it’s a tool in Python used
for installing Python packages, that’s not enough. There’s nothing pip
gives us, please think about it.Additionally,
is master atm usable?Yes, I use it regularly.
Specifcially, I have been able to get the master
running locally, except I see no services against the clusterInternal services are not returned through the admin API, and web-admin
using the admin API, unless you set misc.return_internal_objects to True
in server.conf and restart servers.and neither
am able to add my own by moving them to pickup_dir [ the server picks
them
up since the files vanish from the directory but I never see it turn up
in
web-admin ].Right, I see. Please open a ticket on GH in that case providing
server.log in DEBUG, your Zato version (commit ID if on master) and the
code of services you’re deploying.thanks a lot,
–
Dariusz Suchojadhttps://zato.io
ESB, SOA, REST, APIs and cloud integrations in Python–
Ameno dom, Domi ne reo
Amit
Hi Darius,
Would it be possible to discuss the same over a github issue? Additionally,
is master atm usable? Specifcially, I have been able to get the master
running locally, except I see no services against the cluster and neither
am able to add my own by moving them to pickup_dir [ the server picks them
up since the files vanish from the directory but I never see it turn up in
web-admin ].
How exactly does web-admin get a list of services against a cluster?
On Thu, Jun 19, 2014 at 12:16 PM, Dariusz Suchojad dsuch@zato.io wrote:
On 06/19/2014 06:26 AM, Amit Prakash Ambasta wrote:
My name is Amit and I’ve been trying for the past few weeks to be able to
get zato into a pip ready state so someone could just pip install zato.I am not sure as to how mailing lists work so dropping in a first message
to introduce myself.Hello Amit,
as we have started to talk about it off-list, here are my thoughts on
the idea.First thing is, it’s great that you’d like to help out
It’s really
great to see such an enthusiasm!When thinking of any sort of installers, please always keep in mind that:
pip and PyPI are for installing Python modules and packages Zato is
not a simple Python module nor package.The point above is really important - pip merely installs Python
modules. It’s very good at it and that’s it. Zato is a programming
platform that is written in Python but it doesn’t mean it has to be
installable using a tool that has recently become popular.The point on recent popularity is an important one - over years we
have had easy_install, distribute, distribute2, pip, project forks,
merges, splits and joins - personally I’ve spent enough time on it all
and /perhaps/ now that pip is in Python 3.x things will settle down.I really wish everyone involved in developing Python packaging story all
the best and I really hope things will be clearer now. But I’ve been
using Python since 2.1 and it’s way too early for me to categorically
say pip is the way to go. I need more time to get convinced.In that regards, consider Zato similar to PostgreSQL. The latter being
built using a Makefile but it doesn’t mean one should be able to do
stuff like ‘make download postgresql’.Up until recently, the only Python packaging tool almost capable of
producing result Zato needs was buildout. Some time ago conda has come
around and perhaps conda is something to look at but I’m 100% pip right
won’t handle what we need. Perhaps with time but not now.Like I say, I hope and keep fingers crossed Python’s packaging situation
but there are no packaging problems in Zato that pip solves.In fact, given it’s never been meant to support what Zato needs, I’m
certain it won’t do. But this is because there are certain goals for
Zato installers outside of pip’s scope, not that because pip doesn’t
live up to its own promises.Actually - if you have a look at the very first commit to GH …
https://github.com/zatosource/zato/blob/41476e8c27d0eb309f45762015fbcdc09de8547f/code/install.sh
https://github.com/zatosource/zato/blob/41476e8c27d0eb309f45762015fbcdc09de8547f/code/buildout.cfg
… you’ll already notice that pip will not:
- Update system packages
- Install a system package
- Apply a patch to a dependency
This was 2 years ago and this is how it looks like today
https://github.com/zatosource/zato/blob/master/code/_install-deb.sh
https://github.com/zatosource/zato/blob/master/code/_install-fedora.shAnd it’s all OK - pip simply is not meant for things we need. There’s no
need to use this particular tool if we have a toolbox full of other
options.
- Zato must be able to install on systems that may not even have Python
2.7 alone - think CentOS 6.x or SuSE - and the goal of the installation
process is always to install Zato in a reproducible way.That is, given a bare OS when one does ‘yum install zato’ or ‘apt-get
install zato’ or simply install it from source, it should always install
the same set of packages given the same version of the OS.Builds must always be reproducible, this is a topmost priority. Please
remember that people, me including, support production systems that
aren’t operated by Python programmers and everyone should always have
the same environment given the same build process.If I have a local VM of Ubuntu 12.04.3 LTS up to do date and a Zato user
has the same system then ‘apt-get install zato’ always produces the same
output. There simply can be no exceptions to that process.That point rules out providing dependencies in the form of ‘foo>=1.23’.
These always need to explicitly listed. And conversely, there can be no
dependencies that are not listed in a given requirements file (pip or
buildout).
- To conclude - I like pip for simpler projects, for instance apitest
uses requirements.txt and is generally available through piphttps://github.com/zatosource/zato-apitest
But even in such a simple project as apitest I immediately hit upon a
feature pip doesn’t support - that of warning when a dependency of a
package attempts to install its own dependency I didn’t explicitly list
in requirements.txt.And Zato must support use cases on a order of magnitude harder, like
making sure Python 2.7 is available in the first place and links to
correct system libraries. Or that HAProxy is there.These are real requirements set before a packaging tool and pip doesn’t
deal with them, it’s all simply outside of its scope, at least for now.I honestly am very thankful for your work, it’s terrific to see such a
passion but at that point I’m not convinced pip is something we really,
really need.If you’d still like to work on it, I’d be happy to discuss it with you
here on the list and make sure your works go in the same direction the
rest of the project but right now I just can’t see any issue pip solves
for us.This is open-source so hey, you can do anything you want
are some tickets waiting in the tracker and perhaps you’d rather be
interested in picking up one of these instead?https://github.com/zatosource/zato/issues?milestone=3&page=1&state=open
These are all the tickets that need to be closed before we can cut the
2.0 release. If you’d like to get involved in the project, maybe you
could have a look at them and say a bit about what you’re interested in
generally as Python development goes so that I could suggest a ticket
that you’d find a worthwhile goal or perhaps we’d open a new one for you?What do you think?
Hi Darius
I understand your concerns and accept the fact that pip is not the ideal
tool for zato as a commercial ESB. I’ve stayed with pip mostly due to my
personal requirements[ I run gentoo ] and an interest in python packaging.
I understand the issues you’ve mentioned and pip would indeed not address a
lot of issues which you mentioned above. Hence as far as the packaging bits
go, I make only minor changes to upstream and have forked it for internal
consumption.
At some point I’ll try splitting the setup into zato-installer and pip
packages strictly as a matter of interest and experimentation. I have
primarily been a django developer for the past few years so I am still
trying to wrap my head around how zato works. I hope to be able to
contribute to the issues wrt 2.0 at some point in the short future.
On Tue, Jun 24, 2014 at 2:05 AM, Dariusz Suchojad dsuch@zato.io wrote:
On 06/23/2014 10:18 PM, Amit Prakash Ambasta wrote:
Would it be possible to discuss the same over a github issue?
Sure, naturally.
Just please keep in mind that pip is not the right tool for the job. Pip
not only solves none of the project’s needs but actually re-introduces a
point of failure we’ve recently dealt with.So I would feel very, very bad if I didn’t warn you each time pip’s
usage was suggestedI’ll present you wit a story - a couple of days ago I was working with a
client on a screen share, setting up a new environment as we spoke online.Embarrassingly enough, I could not install Zato from source because
twice in a row Internet connectivity issues prevented the OS I was doing
it on to download things from PyPI.Obviously, it’s no one’s fault really - but can you imagine how bad it
looks when you do such things live?Speaking broadly - so far I installed Zato from source some 200-250
times, say. Out of it, about 10-15% the installation failed because a
dependency could not be downloaded, because a site was down, another one
was undergoing maintenance or an author of a package removed the package
altogether.Perhaps such things are not visible when a project has 10 dependencies
but Zato has 100+ of them.I simply cannot agree to anything like that anymore - hence a great deal
of, and I really mean a lot, effort goes into preparing various build
scripts for Debian/Ubuntu/RHEL/CentOS/SLES.That way packages for 1.1 are precompiled and no one needs to go through
any pains at all. For others, there’s the ability to prepare their own
packages.So just to repeat it - using pip would be a step back. It doesn’t solve
anything and would require bending it to fulfill what we need. There’s
simply no need for it.And I just cannot agree to it simply because it’s a tool in Python used
for installing Python packages, that’s not enough. There’s nothing pip
gives us, please think about it.Additionally,
is master atm usable?Yes, I use it regularly.
Specifcially, I have been able to get the master
running locally, except I see no services against the clusterInternal services are not returned through the admin API, and web-admin
using the admin API, unless you set misc.return_internal_objects to True
in server.conf and restart servers.and neither
am able to add my own by moving them to pickup_dir [ the server picks
them
up since the files vanish from the directory but I never see it turn up
in
web-admin ].Right, I see. Please open a ticket on GH in that case providing
server.log in DEBUG, your Zato version (commit ID if on master) and the
code of services you’re deploying.thanks a lot,
–
Dariusz Suchojadhttps://zato.io
ESB, SOA, REST, APIs and cloud integrations in Python
Also apologies for repeatedly misspelling your name. I just noticed its
Dariusz
On Tue, Jun 24, 2014 at 2:27 AM, Amit Prakash Ambasta <
amit.prakash.ambasta@gmail.com> wrote:
Hi Darius
I understand your concerns and accept the fact that pip is not the ideal
tool for zato as a commercial ESB. I’ve stayed with pip mostly due to my
personal requirements[ I run gentoo ] and an interest in python packaging.
I understand the issues you’ve mentioned and pip would indeed not address a
lot of issues which you mentioned above. Hence as far as the packaging bits
go, I make only minor changes to upstream and have forked it for internal
consumption.At some point I’ll try splitting the setup into zato-installer and pip
packages strictly as a matter of interest and experimentation. I have
primarily been a django developer for the past few years so I am still
trying to wrap my head around how zato works. I hope to be able to
contribute to the issues wrt 2.0 at some point in the short future.On Tue, Jun 24, 2014 at 2:05 AM, Dariusz Suchojad dsuch@zato.io wrote:
On 06/23/2014 10:18 PM, Amit Prakash Ambasta wrote:
Would it be possible to discuss the same over a github issue?
Sure, naturally.
Just please keep in mind that pip is not the right tool for the job. Pip
not only solves none of the project’s needs but actually re-introduces a
point of failure we’ve recently dealt with.So I would feel very, very bad if I didn’t warn you each time pip’s
usage was suggestedI’ll present you wit a story - a couple of days ago I was working with a
client on a screen share, setting up a new environment as we spoke online.Embarrassingly enough, I could not install Zato from source because
twice in a row Internet connectivity issues prevented the OS I was doing
it on to download things from PyPI.Obviously, it’s no one’s fault really - but can you imagine how bad it
looks when you do such things live?Speaking broadly - so far I installed Zato from source some 200-250
times, say. Out of it, about 10-15% the installation failed because a
dependency could not be downloaded, because a site was down, another one
was undergoing maintenance or an author of a package removed the package
altogether.Perhaps such things are not visible when a project has 10 dependencies
but Zato has 100+ of them.I simply cannot agree to anything like that anymore - hence a great deal
of, and I really mean a lot, effort goes into preparing various build
scripts for Debian/Ubuntu/RHEL/CentOS/SLES.That way packages for 1.1 are precompiled and no one needs to go through
any pains at all. For others, there’s the ability to prepare their own
packages.So just to repeat it - using pip would be a step back. It doesn’t solve
anything and would require bending it to fulfill what we need. There’s
simply no need for it.And I just cannot agree to it simply because it’s a tool in Python used
for installing Python packages, that’s not enough. There’s nothing pip
gives us, please think about it.Additionally,
is master atm usable?Yes, I use it regularly.
Specifcially, I have been able to get the master
running locally, except I see no services against the clusterInternal services are not returned through the admin API, and web-admin
using the admin API, unless you set misc.return_internal_objects to True
in server.conf and restart servers.and neither
am able to add my own by moving them to pickup_dir [ the server picks
them
up since the files vanish from the directory but I never see it turn up
in
web-admin ].Right, I see. Please open a ticket on GH in that case providing
server.log in DEBUG, your Zato version (commit ID if on master) and the
code of services you’re deploying.thanks a lot,
–
Dariusz Suchojadhttps://zato.io
ESB, SOA, REST, APIs and cloud integrations in Python–
Ameno dom, Domi ne reo
Amit
Reading _install.sh tells me that linking scipy/numpy to zato_extra_paths
and then bootstrapping should let you create a buildout.
Also, if you would like to try zato on a virtualenv alone, you might try
using packages @ http://pip.done.delhivery.com/packages/
However, as you’d discover I’ve no idea how broken these packages atm are.
On Tue, Jun 24, 2014 at 2:34 AM, Brian Martin bmartin@qualbe.com wrote:
Just a question, is there any sort of documentation our install script for
installing zato from source separate from using debian packages? Is there
a buildout script? I know for me, pip isn’t as big a deal. But being able
to run something in a virtualenv is nice to keep things isolated rather
than going for a full-blown VM.On Mon, Jun 23, 2014 at 4:57 PM, Amit Prakash Ambasta <
amit.prakash.ambasta@gmail.com> wrote:Hi Darius
I understand your concerns and accept the fact that pip is not the ideal
tool for zato as a commercial ESB. I’ve stayed with pip mostly due to my
personal requirements[ I run gentoo ] and an interest in python packaging.
I understand the issues you’ve mentioned and pip would indeed not address a
lot of issues which you mentioned above. Hence as far as the packaging bits
go, I make only minor changes to upstream and have forked it for internal
consumption.At some point I’ll try splitting the setup into zato-installer and pip
packages strictly as a matter of interest and experimentation. I have
primarily been a django developer for the past few years so I am still
trying to wrap my head around how zato works. I hope to be able to
contribute to the issues wrt 2.0 at some point in the short future.On Tue, Jun 24, 2014 at 2:05 AM, Dariusz Suchojad dsuch@zato.io wrote:
On 06/23/2014 10:18 PM, Amit Prakash Ambasta wrote:
Would it be possible to discuss the same over a github issue?
Sure, naturally.
Just please keep in mind that pip is not the right tool for the job. Pip
not only solves none of the project’s needs but actually re-introduces a
point of failure we’ve recently dealt with.So I would feel very, very bad if I didn’t warn you each time pip’s
usage was suggestedI’ll present you wit a story - a couple of days ago I was working with a
client on a screen share, setting up a new environment as we spoke
online.Embarrassingly enough, I could not install Zato from source because
twice in a row Internet connectivity issues prevented the OS I was doing
it on to download things from PyPI.Obviously, it’s no one’s fault really - but can you imagine how bad it
looks when you do such things live?Speaking broadly - so far I installed Zato from source some 200-250
times, say. Out of it, about 10-15% the installation failed because a
dependency could not be downloaded, because a site was down, another one
was undergoing maintenance or an author of a package removed the package
altogether.Perhaps such things are not visible when a project has 10 dependencies
but Zato has 100+ of them.I simply cannot agree to anything like that anymore - hence a great deal
of, and I really mean a lot, effort goes into preparing various build
scripts for Debian/Ubuntu/RHEL/CentOS/SLES.That way packages for 1.1 are precompiled and no one needs to go through
any pains at all. For others, there’s the ability to prepare their own
packages.So just to repeat it - using pip would be a step back. It doesn’t solve
anything and would require bending it to fulfill what we need. There’s
simply no need for it.And I just cannot agree to it simply because it’s a tool in Python used
for installing Python packages, that’s not enough. There’s nothing pip
gives us, please think about it.Additionally,
is master atm usable?Yes, I use it regularly.
Specifcially, I have been able to get the master
running locally, except I see no services against the clusterInternal services are not returned through the admin API, and web-admin
using the admin API, unless you set misc.return_internal_objects to True
in server.conf and restart servers.and neither
am able to add my own by moving them to pickup_dir [ the server picks
them
up since the files vanish from the directory but I never see it turn
up in
web-admin ].Right, I see. Please open a ticket on GH in that case providing
server.log in DEBUG, your Zato version (commit ID if on master) and the
code of services you’re deploying.thanks a lot,
–
Dariusz Suchojadhttps://zato.io
ESB, SOA, REST, APIs and cloud integrations in Python–
Ameno dom, Domi ne reo
Amit