On 10/18/2016 08:07 AM, Adam Harwell wrote:
> If there's no objection to us using gunicorn without it being present in
> g-r, then I don't know if I want to argue strongly for adding it -- the
> only benefit I see to tracking g-r at all is that it lets us continue to
> get free version tracking for our amphora dependencies as they are
> updated in g-r without having to manually tweak them. Once we go away
> from using g-r for our amphora-requirements, our project team has to
> track these dependencies manually. Tweaking the requirements bot to look
> at amphora-requirements.txt as Doug mentioned won't actually do much,
> since the whole point here is that we're including things that aren't in
> g-r so there's no source to update them from.
> So, does everyone at least agree that it's ok for us to *use* gunicorn
> internally on our service-vm image? If so, I'm happy to move forward
> with option #2 if it looks like that'll be the path of least resistance.
> As I said, options 3 and 4 are not really good solutions to this
> particular problem, so in my view we should do whichever is most likely
> to be accepted of options 1 or 2.
>     --Adam

Personally I'm happy with it being in gr, it's not the perfect place
though.  (bindep would probably be better I feel, it's packaged on my

Do you need a specific version (bindep can't handle versions)?

As a packager I'd rather not force the type of server on my users.

Matthew Thode (prometheanfire)

Attachment: signature.asc
Description: OpenPGP digital signature

OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe

Reply via email to