Carl, Eby,
Thanks for taking time to suggest various alternatives. Considering that the
deployment hosts are identical in every as[ect, the approach of moving
virtualenv's with packages pip-installed at build time appears the simplest,
low-overhead approach that can be implemented without hacking the environment
or resorting to custom scripts. I'll go ahead with that option.
Thanks,Bharath
> From: p...@telecommunity.com
> Date: Fri, 23 Aug 2013 15:38:46 -0400
> Subject: Re: [Distutils] Distributable binary with dependencies
> To: reachb...@outlook.com
> CC: distutils-sig@python.org
>
> On Fri, Aug 23, 2013 at 6:45 AM, bharath ravi kumar
> <reachb...@outlook.com> wrote:
> > I'm looking to package an application with all its dependencies for
> > deployment on multiple hosts. I'd like to ensure that there is no
> > compilation or setup step before starting the application in production. An
> > nice to have ability would be to isolate base library dependencies per
> > application (like virtualenv does). Ideally, the development -> deployment
> > lifecycle would involve: (a) Build an application archive with all its
> > dependencies baked in (b) Copy archive to a host in production. (c) Unwrap
> > archive (d) Start services. (Note that the build host & production hosts are
> > identical in architecture, OS patch level and python version).
>
> You can use "easy_install -Zmad deployment_dir application", then
> archive deployment_dir and extract it on the target machines. (Note:
> "application" must be a setuptools-packaged project with its
> dependencies declared, for easy_install to know what to build and
> deploy.)
>
> The "Z" option means "unzip eggs", "m" means "don't worry about the
> target being on sys.path; we're not trying to install a default
> version", "a" means "copy all dependencies, even if locally installed
> already", and "d" means "install libraries and scripts to the
> following directory".
>
> So, the scripts will be put inside deployment_dir with a bunch of
> adjacent subdirectories containing all the compiled and ready-to-use
> libraries. The resulting directory is a portable installation of
> "application": as long as the entire subdirectory is copied to the
> target machines, everything should work just fine. None of the
> dependencies or the app itself will interfere with other Python code
> installed on the target system; it is in a sense a minimal virtualenv
> which will run whatever scripts that easy_install puts in that
> directory.
>
> One note: the target machines *will* need pkg_resources installed, and
> it will not be included in the directory by default. If they don't
> have local copies installed (due to e.g. setuptools, distribute, etc.
> being installed), you can manually copy a pkg_resources.py to the
> deployment directory, and it will be used by whatever scripts are in
> that directory.
>
> While there may be other tools available that support this kind of
> thing, I don't think any of them can do it quite this simply. This
> deployment scenario was actually a key use case for the original
> design of easy_install and eggs, so it actually works pretty decently
> for this.
_______________________________________________
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
