<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jun 24, 2015 at 7:27 AM, Chris Dent <span dir="ltr"><<a href="mailto:chdent@redhat.com" target="_blank">chdent@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="">On Wed, 24 Jun 2015, Sean Dague wrote:<br>
</span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="">
On 06/24/2015 07:57 AM, Chris Dent wrote:<br>
</span><span class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
If the primary reason is so that we can rely on the console_scripts<br>
entry point to handle getting the application somewhere useful then<br>
that too feels a bit crufty, in the sense of "that's a hack".<br>
</blockquote></span></blockquote>
<br>
[snip]<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
The reason I want this is so that the upgrade process for keystone is:<br>
<br>
pip install ./keystone<br>
<br>
And not have to also have knowledge about the contents of the keystone<br>
source directory. Today a lot of installation and upgrade logic for<br>
packages is "left as an exercise for the reader", which means devstack,<br>
ansible, rpms, debs all end up doing a bunch of work beyond pip install.<br>
Minimizing that by bringing more of this back into what pip install does<br>
will make for a more common base moving forward for everyone.<br>
</blockquote>
<br></span>
Makes sense. My only concern would be the somewhat of a mismatch in<br>
semantics between console_scripts and what is not a console script.<br>
<br>
Does anyone who is more familiar with entry points know of an<br>
alternative that will accomplish the same sort of thing?<br>
<br>
If there's not, then awesome, let's do it.<span class="im"><br>
<br>
-- <br>
Chris Dent tw:@anticdent freenode:cdent<br>
<a href="https://tank.peermore.com/tanks/cdent" rel="noreferrer" target="_blank">https://tank.peermore.com/tanks/cdent</a><br>
<br></span></blockquote><div><br></div><div>I tried console_scripts and there is a mismatch between what a console script is and a wsgi script. A wsgi script must export an "application" symbol and the generated console script doesn't. Maybe setuptools will be enhanced someday to also support wsgi scripts but until then I think we're stuck.<br><br></div><div>One thing I should have looked at earlier is how devstack handles horizon, since it's already running in Apache Httpd. The devstack horizon setup uses the wsgi script out of the devstack source directories:<br></div><div><br>    WSGIScriptAlias / /opt/stack/horizon/openstack_dashboard/wsgi/django.wsgi<br><br></div><div>Docs:<br>[1] <a href="https://pythonhosted.org/setuptools/setuptools.html#automatic-script-creation">https://pythonhosted.org/setuptools/setuptools.html#automatic-script-creation</a> -- console_scripts and gui_scripts<br>[2] <a href="http://docs.openstack.org/developer/pbr/#files">docs.openstack.org/developer/pbr/#files</a> -- I couldn't get this to work for some reason<br></div><div><br></div><div>-Brant<br><br></div></div></div></div>