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: mtrein...@kortar.org > > To: Sam Yaple <s...@yaple.net>, OpenStack Development Mailing List (not for > > usage questions) <openstack-dev@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)
signature.asc
Description: PGP signature
__________________________________________________________________________ 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
