Open Stack

On 06/24/2015 02:05 PM, Sean Dague wrote:
> On 06/24/2015 01:51 PM, Brant Knudson wrote:
>>
>>
>> On Wed, Jun 24, 2015 at 7:27 AM, Chris Dent <chdent at redhat.com
>> <mailto:chdent at redhat.com>> wrote:
>>
>>     On Wed, 24 Jun 2015, Sean Dague wrote:
>>
>>         On 06/24/2015 07:57 AM, Chris Dent wrote:
>>
>>             If the primary reason is so that we can rely on the
>>             console_scripts
>>             entry point to handle getting the application somewhere
>>             useful then
>>             that too feels a bit crufty, in the sense of "that's a hack".
>>
>>
>>     [snip]
>>
>>         The reason I want this is so that the upgrade process for
>>         keystone is:
>>
>>         pip install ./keystone
>>
>>         And not have to also have knowledge about the contents of the
>>         keystone
>>         source directory. Today a lot of installation and upgrade logic for
>>         packages is "left as an exercise for the reader", which means
>>         devstack,
>>         ansible, rpms, debs all end up doing a bunch of work beyond pip
>>         install.
>>         Minimizing that by bringing more of this back into what pip
>>         install does
>>         will make for a more common base moving forward for everyone.
>>
>>
>>     Makes sense. My only concern would be the somewhat of a mismatch in
>>     semantics between console_scripts and what is not a console script.
>>
>>     Does anyone who is more familiar with entry points know of an
>>     alternative that will accomplish the same sort of thing?
>>
>>     If there's not, then awesome, let's do it.
>>
>>     -- 
>>     Chris Dent tw:@anticdent freenode:cdent
>>     https://tank.peermore.com/tanks/cdent
>>
>>
>> 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.
>>
>> 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:
>>
>>     WSGIScriptAlias /
>> /opt/stack/horizon/openstack_dashboard/wsgi/django.wsgi
>>
>> Docs:
>> [1]
>> https://pythonhosted.org/setuptools/setuptools.html#automatic-script-creation
>> -- console_scripts and gui_scripts
>> [2] docs.openstack.org/developer/pbr/#files
>> <http://docs.openstack.org/developer/pbr/#files> -- I couldn't get this
>> to work for some reason
> 
> Hmmm... bummer. Oh well.

pbr is actually the one that creates console_scripts for us, as the ones
generated by setuptools are unusable for us (they use entrypoints which
is the reason rootwrap was super slow 8 months ago)

As we have all the bits to produce such scripts in the way we want and
already do so - adding declarative wsgi scripts is likely about 5 lines
of code and I think would be super useful.

(I said most of this to sdague in IRC)