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

[Jeremy Cline]

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.
> > 
> > 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.

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