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