<div dir="ltr">Hi Billy<br><br><div class="gmail_quote"><div dir="ltr">On Thu, 30 Jun 2016 at 17:24 Billy Olsen <<a href="mailto:billy.olsen@gmail.com">billy.olsen@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I suspect that the reactive charming model wouldn't have this issue<br>
due to the ability to essentially statically link the libraries via<br>
wheels/pip packages. If that's the case, it's likely possible to<br>
follow along the same lines as the base-layer charm and bootstrap the<br>
environment using pip/wheel libraries included at build time. As I see<br>
it, this would require:<br>
<br>
* Updates to the process/tooling for pushing to the charm store<br>
* Update the install/upgrade-charm hook to bootstrap the environment<br>
with the requirements files<br>
* If using virtualenv (not a requirement in my mind), then each of the<br>
hooks needs to be bootstrapped to ensure that they are running within<br>
the virtualenv.<br></blockquote><div><br></div><div>I was thinking of something along those lines as well.  I'll spike on something this week to figure out exactly how this might work.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
To make life easier in development mode, the charms can downla<br>
build step before deployment, though certainly for the published<br>
versions the statically linked libraries should be included (which,<br>
from my understanding, I believe the licensing allows and why the<br>
reactive charming/layered model wouldn't have this issue).<br></blockquote><div><br></div><div>That sounds like a neat idea (although building out a layered charm is pretty easy as well).<span style="line-height:1.5"> </span></div></div></div>