[Distutils] Distributable binary with dependencies

[bharath ravi kumar]

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: pje at telecommunity.com
> Date: Fri, 23 Aug 2013 15:38:46 -0400
> Subject: Re: [Distutils] Distributable binary with dependencies
> To: reachbach at outlook.com
> CC: distutils-sig at python.org
> 
> On Fri, Aug 23, 2013 at 6:45 AM, bharath ravi kumar
> <reachbach at 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.
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/distutils-sig/attachments/20130826/df0c6ce9/attachment-0001.html>