Not only is it interesting, it’s awesome :) John
On June 23, 2016 at 5:53:59 PM, Silence Dogood ([email protected]) wrote: I'll check out giftwrap. never heard of it. But interesting. On Thu, Jun 23, 2016 at 7:50 PM, Xav Paice <[email protected]> wrote: > 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 <[email protected]> > > 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 > > [email protected] > > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators > > > > _______________________________________________ > > OpenStack-operators mailing list > > [email protected] > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators > > > > _______________________________________________ > OpenStack-operators mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators > _______________________________________________ OpenStack-operators mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
_______________________________________________ OpenStack-operators mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
