gh-6: add -i/--issue and -s/--section flags to blurb add

[picnixz]

Fixes #6. This is an alternative to #15.

@hugovk I've taken out your way of handling positional arguments (but would you consider a PR which refactors blurb in order to use argparse instead?). If you prefer --gh, I can also rename the variable!

[hugovk]

would you consider a PR which refactors blurb in order to use argparse instead?

That could make things easier, but I've not used subcommands much in argparse, how are they? We'd need to make sure all the commands and options work in the same way, blurb is used in a few different bits of automation and we wouldn't want to break any of them.

[picnixz]

That could make things easier, but I've not used subcommands much in argparse, how are they? We'd need to make sure all the commands and options work in the same way, blurb is used in a few different bits of automation and we wouldn't want to break any of them.

From my personal usage of subcommands, it works the same. Actually, a subcommand is just an action that invokes an ArgumentParser. However, it might indeed come with some corner cases which I would first extensively test. If you can tell me where it's being used in automaton parts, then I'd be glad to check if I can make the transition.

[hugovk]

If you can tell me where it's being used in automaton parts, then I'd be glad to check if I can make the transition.

Hmm, well at least here:

• https://github.com/python/blurb_it / https://blurb-it.herokuapp.com/
• https://github.com/python/release-tools (automating some of https://peps.python.org/pep-0101/)
• https://github.com/python/cpython/blob/main/Doc/Makefile
• https://github.com/python/cpython/blob/main/Tools/patchcheck/patchcheck.py

[larryhastings]

Some initial comments. I'll confer further with Hugo.

[picnixz]

Thank you Larry for your comments. I'll address them tomorrow (I don't have access to the project now)

[hugovk]

Testing matching the sections, blurb add --section core works, but not:

❯ blurb add --section built
Invalid section name: 'built'

Choose from the following table:

+-------------------+
| Security          |
| Core and Builtins |
| Library           |
| Documentation     |
| Tests             |
| Build             |
| Windows           |
| macOS             |
| IDLE              |
| Tools/Demos       |
| C API             |
+-------------------+

Or:

❯ blurb add --section api
Invalid section name: 'api'

Choose from the following table:

+-------------------+
| Security          |
| Core and Builtins |
| Library           |
| Documentation     |
| Tests             |
| Build             |
| Windows           |
| macOS             |
| IDLE              |
| Tools/Demos       |
| C API             |
+-------------------+

Should they?

[picnixz]

Mmmh, I think I only matched from the beginning, not inside. Otherwise, you write 'l' and have a lot of matches (library, core and builtins, tools, etc). And I didn't want to special cases. But maybe we can use aliases? I don't remember now if 'capi' works (but maybe it should)

[hugovk]

Mmmh, I think I only matched from the beginning, not inside. Otherwise, you write 'l' and have a lot of matches (library, core and builtins, tools, etc).

Yeah, that's not so useful.

And I didn't want to special cases. But maybe we can use aliases? I don't remember now if 'capi' works (but maybe it should)

"capi" doesn't work:

❯ blurb add --section capi
Invalid section name: 'capi'

Choose from the following table:

+-------------------+
| Security          |
| Core and Builtins |
| Library           |
| Documentation     |
| Tests             |
| Build             |
| Windows           |
| macOS             |
| IDLE              |
| Tools/Demos       |
| C API             |
+-------------------+

I don't think we necessarily need to match "builtins" -> "Core and Builtins" or "demo" -> "Tools/Demos", but "capi" -> "C API" would help, and maybe also "api" -> "C API"?

[picnixz]

I don't think we necessarily need to match "builtins" -> "Core and Builtins" or "demo" -> "Tools/Demos", but "capi" -> "C API" would help, and maybe also "api" -> "C API"?

I ended up making them match like that (the tests should reflect what is now possible). I don't have a better way to cover the use cases so don't hesistate to tell me which cases should be checked.

[larryhastings]

Would it be sufficient to create a "nickname map", like

{ "".join(section.split()).lower(): section for section in sections }

[picnixz]

{ "".join(section.split()).lower(): section for section in sections }

Yes. But to construct additional patterns, I needed to use:

    _sanitized = re.sub(r'[ /]', ' ', _section)
    _section_words = re.split(r'\s+', _sanitized)
    _section_names_lower_nosep[_section] = ''.join(_section_words).lower()

(Your suggestion is in my case implemented as ''.join(_section_words).lower())