[PATCH 2/2] Remove pwclient

[Stephen Finucane]

On Mon, 2018-10-22 at 16:55 +0100, Stephen Finucane wrote:
> 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).

Now that the ozlabs instance has been updated to v2.1, we have access
to the subject_match feature and so I'd like to proceed with this
migration. The 'patchwork/pwclient' repo is seeded and I have a large
rework series lined up and ready to go. Is there any other reason not
to do this, given my previous reply?

Stephen

> > 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
> 
> _______________________________________________
> Patchwork mailing list
> Patchwork at lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/patchwork