Implement coh tag command

[bswck]

Closes #6

[bswck]

Let me know if we want some acknowledgement output, such as "Successfully created tag ..." (git doesn't print it out, but git always accepts an absolute name, so it has an excuse)

[jaraco]

Looks good. I have a few nitpicks and some suggestions about naming and execution.

[bswck]

I'm not fine without a demonstrated use case of this command. Let's just not test it locally yet. I'll add some doctests.

[jaraco]

Let me know if we want some acknowledgement output, such as "Successfully created tag ..." (git doesn't print it out, but git always accepts an absolute name, so it has an excuse)

I'm okay without the message. I can see how it could be useful, though. I frequently run jaraco.develop.finalize and only figure out what version it created after I push and see the new tag pushed and am surprised to see it created something unexpected (because I had failed to delete a tag, for example). I don't feel strongly about it, so I'll leave it to your instincts.

[bswck]

I'm not fine without a demonstrated use case of this command. Let's just not test it locally yet. I'll add some doctests.

Maybe we could roll out a fixture to create a temporary repo.
Indeed, we can.

[jaraco]

I'm not fine without a demonstrated use case of this command. Let's just not test it locally yet. I'll add some doctests.

Maybe we could roll out a fixture to create a temporary repo.

jaraco.vcs has such a thing, but it's probably not yet exposed except for internal use. We could move that into jaraco.vcs.fixtures and expose it as a pytest entry point. Would that help?

Also, don't feel obliged to make it a doctest. If you'd rather write proper unit tests (and that's what most of the world besides me would expect), feel free to create one in tests/test_*.

[bswck]

I'm not fine without a demonstrated use case of this command. Let's just not test it locally yet. I'll add some doctests.

Maybe we could roll out a fixture to create a temporary repo.

jaraco.vcs has such a thing, but it's probably not yet exposed except for internal use. We could move that into jaraco.vcs.fixtures and expose it as a pytest entry point. Would that help?

Also, don't feel obliged to make it a doctest. If you'd rather write proper unit tests (and that's what most of the world besides me would expect), feel free to create one in tests/test_*.

In case it's a proper unit test (which is the best as I think about it), we could monkeypatch subprocess.run and validate against the produced argument list.
EDIT: I'm afraid that could break repo detection. Nevermind.

[bswck]

jaraco.vcs has such a thing, but it's probably not yet exposed except for internal use. We could move that into jaraco.vcs.fixtures and expose it as a pytest entry point. Would that help?

Definitely, yes! Tracking in jaraco/jaraco.vcs#36.

[jaraco]

In case it's a proper unit test (which is the best as I think about it), we could monkeypatch subprocess.run and validate against the produced argument list.

If we go that route, I'd recommend pytest-subprocess.

[bswck]

In case it's a proper unit test (which is the best as I think about it), we could monkeypatch subprocess.run and validate against the produced argument list.

If we go that route, I'd recommend pytest-subprocess.

Looks awesome, thanks! However my instinct is that it is more suitable in this specific case to test against the actual Git, as it is done in the project we depend on, i.e. jaraco.vcs.

[jaraco]

jaraco.vcs has such a thing, but it's probably not yet exposed except for internal use. We could move that into jaraco.vcs.fixtures and expose it as a pytest entry point. Would that help?

Definitely, yes!

I took a look at the fixtures there, and they're a little peculiar. They create two commits with a bar/baz file. Probably we'll want something more generalizable.

[bswck]

I'm okay without the message. I can see how it could be useful, though. I frequently run jaraco.develop.finalize and only figure out what version it created after I push and see the new tag pushed and am surprised to see it created something unexpected (because I had failed to delete a tag, for example). I don't feel strongly about it, so I'll leave it to your instincts.

As discussed in Discord, this hesitation will be solved by verbosity levels.
I'll simply put a print here and then introduce verbosity levels in another PR.

[bswck]

Wait a sec. I'll put that print on its place.

[bswck]

Well, the project is entirely untested yet. I guess we can add tests later, as soon as I get some more time.

[jaraco]

I used the feature to cut the next release of this project:

 coherent.cli main 🐚 py -3.12 -m pip-run . -- -m coherent.cli tag minor
Created tag 0.4
 coherent.cli main 🐚 git tags | head
v0.4.0
v0.3.2
v0.3.1
v0.3.0
v0.2.0
v0.1.0

[bswck]

Ahhh, I didn't use the result of semver(name).
Sorry.

[jaraco]

Ahhh, I didn't use the result of semver(name).
Sorry.

No biggie.