Can I suggest that using the tool https://github.com/openstack/giftwrap might make live a bunch easier?
I went down a similar path with building Debs in a venv using dh_virtualenv, with some good success when I sorted the shebang. I later found that the debs produced by Giftwrap are not only very easy to build and test, but also take a bunch less effort to maintain and create new packages for new things. To run the resulting code, I just symlink the ${venv}/bin/$binary to /usr/local/bin and run the thing using very similar init scripts to the ones supplied by the distro packages. Works like a charm, because the shebang in the binary points at the venv, not the system python. I do, however, package the init scripts, sample configs, etc in a separate .deb, which is really very quick and easy and allows me to control the bits I want to, and let Giftwrap take care of the OpenStack code repos. On Thu, 2016-06-23 at 23:40 +0000, Matt Joyce wrote: > I want the script to dynamically instantiate the venv is call activate > this at execution time and deactivate when done. > > > > On June 23, 2016 5:12:07 PM EDT, Doug Hellmann <d...@doughellmann.com> > wrote: > Excerpts from Silence Dogood's message of 2016-06-23 15:45:34 -0400: > I know from conversations that a few folks package their > python apps as > distributable virtualenvs. spotify created dh-virtualenv > for this. you > can do it pretty simply by hand. > > I built a toolchain for building rpms as distributable > virtualenvs and that > works really well. > > What I'd like to do is make it so that every app that's > built as a > virtualenv gets setup to automatically execute at call time > in their > virtualenv. > > I see two options: > > 1) Dynamically generate a wrapper script during build and > put it in the > RPM. Call the wrapper. > > 2) Created a dependency global module ( as an rpm ) set it > as a > dependency. And basically it'd be an autoexecuting import > that > > instantiates the virtualenv. it would probably know all it > needs to > because I am building all my packages to an internal > standard. Then when > building the APP rpm all I need to do is inject an import > into the import > chain if it's being built as a virtualenv. Then I have what > are > effectively statically compiled python apps. > > I like 2. But 1 isn't very bad. Both are a little hokey. > > Was curious if folks might have a preference, or a better > idea. > > Thanks. > > Matt > > I'm not sure what you mean by a "wrapper script". If you run the > Python console script from within the virtualenv you've packaged, > you shouldn't need to do anything to "activate" that environment > separately because it should have the correct shebang line. > > Are you seeing different behavior? > > Doug > > > ______________________________________________________________ > > OpenStack-operators mailing list > OpenStack-operators@lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators > > _______________________________________________ > OpenStack-operators mailing list > OpenStack-operators@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators _______________________________________________ OpenStack-operators mailing list OpenStack-operators@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators