Closed kaushalmodi closed 5 years ago
Hey. Sorry to hear about the confusion. I almost sent you a specific update recommendation, too (I sent one to https://github.com/c-blake/cligen/issues/103#issuecomment-493694116).
I can see the confusion in that I say TYPE.FIELD for the general but INSTANCE.FIELD for the specific, but I do say INSTANCE.FIELD in the two examples on the right hand side right after the general. I realize capital and lowercase C are very similar in most fonts, though "cl" for "command-line" is an ancient and well known abbreviation (most often used as the start of CLI).
I wasn't sure how to emphasize that you don't have to use the convenience global var clCfg
from the module. You can declare/define your own either from scratch or using clCfg as a template, and pass it via the new macro parameter cf
. So, maybe you're saying I should use lowercase 'C' throughout that table part, and then explain you don't have to use the global? (btw, you're welcome. :-)
(edit: markdown ate my bracketed tokens.)
Also, linked in that https://github.com/c-blake/cligen/issues/103#issuecomment-493694116 you see a new versionFromNimble
that lets you just have just one place were you edit the version string - the nimble file. Unless you're using some git hash version string instead of an easier to understand numeric-ish one.
You can declare/define your own either from scratch or using clCfg as a template, and pass it via the new macro parameter cf
Understood, I read your notes in hurry.
Unless you're using some git hash version string instead of an easier to understand numeric-ish one.
I use git describe --tags HEAD
that's the best of both worlds (1: readable numeric version, and 2: git hash). That git command returns just the tag name if the HEAD is tagged. If the HEAD has newer commits after the last tag, it returns a string containing the last tag + the git hash.
Ah. Fine point re: best of both worlds version strings. I updated the example in testVersion.nim
to use that. Also takes Unix head
out of the example, making the example more portable.
I'm open to re-wording suggestions on the RELEASE_NOTES, but if you don't have anything, we can maybe close the issue. No rush, though. It's hard to explain some things and confusion is in some ways a fleeting and precious resource. :-)
heh, isn't that crazy?
Yeah. You & I are pretty in sync in the literal sense! I was thinking that as I pressed enter and saw the update.
Also, I'm unsure if a "like/emoji" use on a thread is sufficient to get you and @pb-cdunn notified about the just-closed very long standing issue https://github.com/c-blake/cligen/issues/2 / https://github.com/c-blake/cligen/issues/30. So, I'll mention it here in case you're interested. Probably best to reply on one of those threads if you reply.
I think 3-ish years ago when it first surfaced one could get the doc comments for fields out of the AST to avoid duplication in the new xhelp
, but I think they may no longer be present. Perhaps nim core would support them again by popular demand? Some attempt was already made https://github.com/nim-lang/Nim/issues/8516, but I believe not well received.
Also, if anyone has any thoughts of how I can avoid the 'x'
in xhelp
and friends, I am all ears.
Never mind about the 'x'
in xhelp
bit. I figured out an internally ugly but externally fine workaround.
Hello,
I was a bit confused when the instructions for fixing the backward-incompatible changes in the Release Notes didn't work: https://github.com/c-blake/cligen/blob/master/RELEASE-NOTES.md#version-0928
Then looking into the tests, I realized that I need to do
clCfg.version
, and notClCfg.version
.btw thanks for continually maintaining and updating this package!