[PATCH 2/2] Remove pwclient

[Stephen Finucane]

On Tue, 2018-10-23 at 01:31 +1100, Daniel Axtens wrote:
> Stephen Finucane <stephen at that.guru> writes:
> 
> > Let's start managing this via a separate project, which will allow the
> > client to evolve separately from the server. No redirect is added for
> > the old '/pwclient' URL as it seems wiser to return a HTTP 404 error
> > code.

So...

> I can't say I'm thrilled by the idea. It adds complexity and I don't
> know what it would make easier. Presumably patches for it would still go
> to this list and be reviewed in the usual way, so I'm not sure how it
> would help workflow.

Yup, I plan on keeping development on the same mailing list, if at all
possible (more on this in a bit).

> It's also a single file at the moment, so it's not like it's so
> complex that it should be spun out to simplify things...

But this is changing. There are two things I'd like to do here that
make shipping this separately seem like a a smarter thing.

 * I want to start shipping pwclient on PyPI so I can just 'pip
   install' wherever I need it (and maybe 'dnf install', in the
   future).

 * I want to add REST API support but would rather not duplicate the
   underlying client in git-pw and pwclient (and whatever other clients
   may be developed in the future). To this end, I'd like to develop a
   'pwlib' library that will provide a generic API client, meaning
   'pwclient' and 'git-pw' will simply provide the user chrome.

These two points are related. Assuming we ship this on PyPI, we're
going to need to add some of distribution tooling (pbr, in this case,
though setuptools or plain old distutils would also be valid options).
I'll also distribution tooling if I want to follow through on 'pwlib'
plan, both to allow 'pwlib' itself to be distributed via PyPI and so
'pwclient' can pull this in as part of it's installation (I really
don't want to vendor pwlib in-tree). All of this means copy-pasting the
script will no longer be an option and the single file we currently
have will grow into multiple files before long. While could keep
developing pwclient (and optionally pwlib) in-tree, doing so makes life
harder for us with regard to things like versioning, documentation,
distribution, etc. Similarly, while we could get away with it for
single file script, it seems wrong to package multiple complex projects
within the same tree, each with their own versioning, documentation,
and release processes. The server will always take priority, meaning
things like tags, the 'docs' directory, 'tox' files etc. will apply
first and foremost to that project.

'git-pw' is already its own project and I think this has allowed it to
develop faster than it might have done were it found in tree. The only
thing I haven't done with this is develop it fully on the list (mostly
because I think of it as a third-party sort of tool) but we can
definitely continue to develop pwclient on list. In fact, the Patchwork
2.1 'project.subject_match' feature allows us to this (and gives us a
way to dog food the feature).

> Do you have a plan to avoid losing the git history if you do this move?

Yup, I've already pulled this out (strictly as a test, until we make a
decision here). The history is retained [1] and I've documented the
steps in the repo itself [2]. I've also pushed up some of the future
changes I have prepared [3], which see us breaking up this monolithic
file into smaller chunks, in preparation for the eventual addition of
REST API support along with some smaller fixes.

> I am somewhat biased because I almost always just invoke pwclient from
> the project directory as patchwork/bin/pwclient, so this would totally
> break my usecase, but I realise that's not a valid reason per se.

Stephen

> Regards,
> Daniel

PS: As an aside, I do think this shows an interesting difference in our
backgrounds shows up :) I'm used to working with multiple different
repos in OpenStack, where everything is split out into smaller units
and versioned APIs ensure different components talk to each other. As
such, splitting this out feels natural to me. However, I guess the
kernel, with it's monolithic repo, does things differently and I'm
guessing tooling for that is all kept in-tree? Interesting, in any
case.

[1] https://github.com/getpatchwork/pwclient/commits/master
[2] https://github.com/getpatchwork/pwclient/commit/23fd64ad3
[1] https://github.com/getpatchwork/pwclient/commits/devel