Open Stack

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 <doug at 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 at lists.openstack.org
>         http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
> 
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators