On 06/24/2015 07:57 AM, Chris Dent wrote: > On Wed, 24 Jun 2015, Sean Dague wrote: > >> So on https://review.openstack.org/#/c/194442 ... I was kind of thinking >> we'd be able to get keystone-wsgi-public into a bin directory. I put up >> a half baked sketch of this idea in >> https://review.openstack.org/#/c/195044. Would be curious if some >> version of that could be made to work here. > > I remain somewhat confused on why you want this? > > It's a fairly common convention for the module which has the wsgi > 'application' global to live somewhere in the "web tree" (/var/www/ etc) > or just some random location that is referenced from the hosting server. > > Putting in */bin doesn't has some risk of confusion because you > shouldn't really run the wsgi script in any normal sense of the word > (from the command line, from cron, whatever). If you've set your > wsgi app up so that is possible then you're conflating purposes and > that's bad mojo. Your patch has exceptions to watch out for that, > but it seems...crufty? > > 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". > > That may be perfectly reasonable stuff to do given the constraints > and lack of other options but I thought I would check in. > > (I happen to be working on making this a reality for gnocchi's > devstack plugin at the moment and your message popped up at exactly > the moment when I needed a reference to in progress reviews on this > topic. Thanks.)
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. -Sean -- Sean Dague http://dague.net __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev