[Distutils] Deployment with setuptools: a basket-of-eggs approach

[Mars]

On 11 Apr 2006 10:40:35 +0200, Iwan Vosloo XXXXX wrote:
>
> Hi Maris,
>
> what do you mean by 'deploying' an egg to the SharedDirectory?  Will
> you install it there, or merely put it there so that installs
> elsewhere can fetch the egg from the repository in SharedDirectory?
>
>
> I also wondered what platforms are involved in your environment?
>
> -i
>

Hi Iwan.  According to the documentation for the pkg_resources API,
eggs need to be placed on sys.path somehow for the 'require'
function's automatic resource discovery to work.  The easiest way to
do this is to add the SharedDirectory to the PYTHONPATH.

With respect to deployment, I believe that simply copying the .egg to
the SharedDirectory should be enough.  This is similar to the
instructions in the easy_install documentation under 'Installing on
Un-networked Machines'.  Thus, developers would execute the following:

% easy_install -f /opt/eggs -zmaxd /opt/eggs mypackage

This will have the effect of building and copying all eggs to the
SharedDirectory, as well as copying all third-party eggs and
dependancies.

As an aside, this raises some interesting questions: should
third-party eggs be treated as run-time data, and live with the
application, or should they be treated the same as all of our internal
eggs?  What is this the most efficient way to upgrade versions?  Also,
the latter approach leaves some important questions about open-ended
versioning.

For example, what if I have a chain of dependancies, like so:

MyPackage-1.0 -> eggA-1.0 -> eggB-1.0

What happens if I upgrade to eggB-2.0, which has an API that is
incompatible with eggB-1.0?  If I originally stated the dependancy as
'require(eggB)', I now have to go back and force eggA-1.0 to use the
earlier version of eggB somehow.  If it is a third-party package, I am
in trouble, as I may not be able to force a specific version.  I would
then have to test all combinations of dependancies across all
applications and versions...

So, I just re-discovered a form of DLL Hell....

I could impliment a policy of freezing the dependancies to a specific
Major and Minor version when an application or package states it's
requirements.  So a developer _must_ state the requirement as
'require(eggB==1.0)'.  The onus then falls on the developer to expand
the range of supported versions of dependancies as they are published
(which is what a good unit test suite will do).

Anyway, as far as platforms are concerned, we have a mix of Windows
and Linux i386 systems, no 64bit systems.  Directory sharing is
implemented through CIFS (Samba).  I should also mention that we are
not working with modules that contain C extensions.

I hope this answers your questions,
Maris

P.S. I CC'd this to distutils-sig, as I feel there is some information
here that other people may find valuable.