Open Stack

Not only is it interesting, it’s awesome :)

John


On June 23, 2016 at 5:53:59 PM, Silence Dogood (matt at nycresistor.com) wrote:

I'll check out giftwrap.  never heard of it.  But interesting.

On Thu, Jun 23, 2016 at 7:50 PM, Xav Paice <xavpaice at gmail.com> 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 <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
>
>
>
> _______________________________________________
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-operators/attachments/20160623/ab9aa74b/attachment-0001.html>