[PATCH 2/2] Remove pwclient

Tue Jun 11 11:31:38 AEST 2019

Stephen Finucane <stephen at that.guru> writes:

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

Yep, go ahead.

I still don't love it as an approach, but I also want to make sure
pwclient development happens and especially that we can kill off xmlrpc,
and this is clearly the best way to free you up to do it.

I'd be keen for us to package it as a deb and/or a snap as well for the
benefit of those of us not in Fedoraland. Remind me to do this at some
point :)

Regards,
Daniel

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