[RFC] Add a setup.py so Patchwork can be pip-installed

Daniel Axtens dja at axtens.net
Fri May 8 16:27:06 AEST 2020


Daniel Axtens <dja at axtens.net> writes:

> Jeremy Cline <jcline at redhat.com> writes:
>
>> Hi Stephen,
>>
>> On Thu, May 07, 2020 at 02:29:30PM +0100, Stephen Finucane wrote:
>>> On Tue, 2020-04-28 at 17:36 -0400, Jeremy Cline wrote:
>>> > Recently I needed to deploy Patchwork and I noticed it was missing a
>>> > setup.py. This is a first draft at adding one and making Patchwork easy
>>> > to install with pip.
>>> > 
>>> > To do this, static files and templates are moved within the Python
>>> > package. "htdocs" is renamed to "static" which is the default location
>>> > Django searches for static files. The two templates directories have
>>> > been merged - I'm not sure why there are two so this perhaps breaks
>>> > something I'm not aware of.
>
> I'm not generally opposed to having a setup.py, but the moving around of
> files worries me a little bit; I'd want to check to see it doesn't break
> anyone using a webserver to serve the static files directly without
> going through Django. It probably does! - I just want to check and be

* s/It probably does!/It probably doesn't break anything!/

>>> > 
>>> > With this change you should be able to do something like:
>>> > 
>>> > $ python3 setup.py sdist
>>> > $ python3 -m venv ~/.virtualenvs/pw
>>> > $ source ~/.virtualenvs/pw/bin/activate
>>> > $ pip install dist/patchwork-3.0.0a1.tar.gz
>>> > $ DJANGO_SETTINGS_MODULE=patchwork.settings.dev PW_TEST_DB_TYPE=sqlite \
>>> >     django-admin migrate
>>> > $ DJANGO_SETTINGS_MODULE=patchwork.settings.dev PW_TEST_DB_TYPE=sqlite \
>>> >     django-admin runserver
>>> > 
>>> > I poked around the web UI and everything seems to work as expected, but
>>> > it's quite likely I've missed something. This change would obviously
>>> > also require updating the installation documentation, but before I go
>>> > any further I'd love some feedback on this. Is this something people are
>>> > interested in?
>>> > 
>>> > My motivation for this is that I've got a little Django app that runs
>>> > alongside Patchwork and would prefer it to be a simple "pip install" to
>>> > get everything set up.
>>> 
>>> Sorry for the delay getting to this /o\ I've considered doing this
>>> myself for some time and the main reason I hadn't was because Patchwork
>>> isn't really packaged as a library or something reusable - it's an
>>> application (in the packaging sense of the word [1]). As such, I'm not
>>> sure how much sense there would be in publishing Patchwork to PyPI and,
>>> for me at least, a setup.py file only real makes sense in that context
>>> [2].
>>> 
>>> With that said, you've suggested that this is beneficial for you at
>>> least. Could you go into a little more on this? I'd have suspected an
>>> Ansible playbook or production Docker container to be far more useful
>>> because they'd include things like nginx/Apache setup, etc. Is that not
>>> the case?
>>> 
>>
>> No worries about the delay, thanks for taking a look.
>>
>> What I'm doing is a bit odd, I suppose, but perhaps explaining what I'm
>> up to will make things clearer. We've got some people who like
>> developing via email, and some people who want to use GitLab, so I
>> decided to just bridge the two so patches and reviews end up as emails
>> and merge requests regardless of where they're submitted. Of course,
>> parsing and tracking the email is a big job, but Patchwork has already
>> done all the hard work so...
>>
>> I created another Django application that depends on Patchwork, adds a
>> few new URLs, and includes a few event handlers on the Patchwork
>> database models. So even though it's not really the intention of
>> Patchwork, I'm using it a bit like a library and being able to express
>> the dependency in my own Python package is handy.
>>
>
> Nifty.
>
> -- d
>
>> One of the great things about Django apps are their reusability (even if
>> you never imagined anyone would do something so silly) and bundling them
>> up in Python packages makes it much easier to extend. It also, I think,
>> simplifies your installation documentation because instead of having
>> people untar the release and potentially mess with their Python path it
>> becomes a simple "pip install".
>>
>> I am using this in addition to an Ansible role so it's not a *huge*
>> deal, it's just a bit awkward.
>>
>> Thanks,
>> Jeremy
>>
>> _______________________________________________
>> Patchwork mailing list
>> Patchwork at lists.ozlabs.org
>> https://lists.ozlabs.org/listinfo/patchwork


More information about the Patchwork mailing list