Open Stack

On 17-12-19 19:50:59, Sam Yaple wrote:
> > -------- Original Message --------
> > Subject: Re: [openstack-dev] [requirements] adding uwsgi to global-requirements
> > Local Time: December 19, 2017 6:34 PM
> > UTC Time: December 19, 2017 11:34 PM
> > From: mtreinish at kortar.org
> > To: Sam Yaple <sam at yaple.net>, OpenStack Development Mailing List (not for usage questions) <openstack-dev at lists.openstack.org>
> >
> >> We don't want to dictate how people are deploying the webapps, instead we say
> >> we use the normal interfaces for deploying python webapps. So if your used to
> >> use mod_wsgi with apache, gunicorn + ngix, or uwsgi standalone, etc. you can do
> >> that. uwsgi in this context is the same as apache. It's not actually a
> >> requirement for any project, you can install and run everything without it, and
> >> in fact many people do.
> >>
> >> The other half of this is that just pip installing uwsgi is not always enough
> >> to actually leverage using it with a webserver. You also need the web server
> >> support for talking to uwsgi. If that's how you use choose to deploy it, which
> >> is not always straightforward. For example, take a look at how it is installed
> >> in devstack to make uwsgi work properly with apache. [3] There are also other
> >> concerns using pip to install uwsgi. uWSGI is a C application and not actually
> >> a python project. It also supports running applications in several languages[4],
> >> not just python. The pypi published install is kind of a hack to download the
> >> tarball and compile the application with only the python bindings compiled.
> >> The setup.py literally calls out to gcc to build it, it's essentially a makefile
> >> written in python. [5][6]
> >>
> >> So what advantage do we get by adding it to global requirements when it's not
> >> actually a requirement for any project, nor is it even python code?
> 
> Not to discount the rest of your reply, but it does seem geared toward the idea that this would force people to use uwsgi.
> 
> The advantage is quite singular in my opinion, using upper-constraints.txt as a pinning mechanism for testing the same version of uwsgi everywhere. Additionally, projects do consume global-requirements.txt and upper-constraints.txt and build _all_ wheels listed within. If uwsgi is not in that list, it is an external package that must be specified to be built, with appropriate version pinning now ona per-project basis.
> 
> The fact that uwsgi is widely used, even as an implementation detail, is the strongest arguement i have for shared version control of it.
> 

So what happens when someone wants to use gunicorn or add another wsgi server
to be tracked by the requirements repo?  One of the the things we are around
for is so projects know what library to use for X.  We generally don't have
any library that provides the same function as another without very good
reason (the kafka stuff comes to mind).

Is there any project that imports uwsgi python libraries as a dependency (or
plans to)?  If not, why would we tracking it?

-- 
Matthew Thode (prometheanfire)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20171220/f7606b31/attachment.sig>