Where to put blurb for generating Misc/NEWS

[brettcannon]

I had suggested putting it into Tools/ while @ncoghlan in #6 suggested either here or as its own repo (I assume under the Python organization). I'm not sure if @larryhastings has an opinion on this or not.

The reason I suggested Tools/ was so that people didn't have to do a separate checkout to generate a NEWS file.

Now if we have a static web page that you can access from github.io for generating the file then that becomes less of an issue. We also require people to install sphinx in at least a venv to build the docs so sticking blurb on PyPI and having people install it isn't that burdensome either (especially since ./python -m venv works with a built CPython interpreter). But it's still a question of whether we want to add this extra step for contributors or not.

If we put blurb here then we begin to centralize our developer tooling so there's a central place to check out and find what tools we have. Doing it in a separate repository means blurb gets its own issue tracker, doesn't have to share Travis with other tools, etc.

If we are not going to put the tool in Tools/ then my vote would be to put it here. It's a simple enough thing that sharing it with cherry_picker won't be a burden as I don't really see the tool changing that much once we settle on #66 and have done a couple releases with it.

[ned-deily]

I agree with @ncoghlan about not putting it into CPython Tools/ since it is a tool that needs to work across branches. I don't have a big preference where to put it but in python/core-workflow alongside of cherry-picker seems fine.

[larryhastings]

I just write 'em, I don't tell you where to put 'em.

A "static" web page is presumably no big deal. Optimally the page would have some JavaScript but no server-side dynamic generation.

[ncoghlan]

The advantages I see to putting it here:

• vs /Tools: we only have one variant of the tool to maintain, rather than one-version-per-branch
• vs it's own repo: it makes it clear that we don't intend for this to be generally useful outside the CPython's workflow

And as a general policy, any time a tool grows a complex enough test suite that sharing the common core-workflow CI instance is deemed a problem, then we can look at giving that tool its own repo (in practice, I think most of them will be tested by CPython's CI).

Finally, we don't even need to publish this on PyPI (although we should probably reserve the name) - the make venv command in the docs directory can be updated to use a VCS install from tags or commit IDs in this repo (so there'd still be a per-branch CPython change in order to do a new "release" of blurb, giving each branch a chance to rebuild the NEWS file with it, but it would be per-blurb-release rather than per-blurb-change, and just touch the make venv command).

[brettcannon]

OK, so it sounds like blurb should just go here!

[larryhastings]

Definitely we should reserve the name on PyPI. I suspect the tool will be very stable; certainly its data files will be, so different versions of the tool should be pretty interoperable. And it'd be nice if "pip3 install blurb" worked.

[ncoghlan]

Name is reserved on PyPI, with Brett and myself as initial co-owners: https://pypi.python.org/pypi/blurb

Happy to add you as well Larry - just let me know your PyPI username (I was able to get Brett's from the caniusepython3 metadata)