search

c-blake / cligen

Nim library to infer/generate command-line-interfaces / option / argument parsing; Docs at
https://c-blake.github.io/cligen/
ISC License
508 stars 24 forks source link

Support for n-2 #85

Closed genotrance closed 5 years ago

genotrance commented 5 years ago

Per the nimble file, cligen supports Nim >= 0.19.0. I'd like to support 0.18.0 as well in nimterop but since I depend on cligen, it isn't possible.

Is it possible to enable support for the older compiler? It will allow us to provide support for the long tail.

c-blake commented 5 years ago

I wasn't very cautious about just cranking up the requirement. I bet my current works with 0.18.0. Not sure, though. The only sorts of dependencies are on some macro changes whose Nim versions I don't recall exactly.

Do you have a Nim 0.18.0 environment and an 80-column terminal around on Unix to run test.sh? If that test runs to success I can just move the nimble file. Happy to do that. A bit more work for me to get a Nim 0.18.0 environment set up on my end.

genotrance commented 5 years ago

Sure I'll try when I get a chance.

c-blake commented 5 years ago

I looked into this a bit more. Pre-0.19.0 support of last release cligen would need a lot of work that I think is long-term not worthwhile. There was a big transition in seq/etc. being able to be nil last Summer. I did a lot of coding around that with no backward compatibility in mind. Re-doing all that to be general enough to support both pre/post new-nil-world order seems not worth it. There is probably some old release of cligen you could depend upon that would work with 0.18.0, but I doubt it would work with newer >=0.19 Nim. The newer cligens have a lot of different features, cligen-0.9.18 in particular. I think (Nim 0.19.*, cligen-0.9.18) would be good long-term dependencies. I just tested it again with Nim 0.19.0 successfully.

At the moment with my unreleased devel cligen, Nim 0.19.0 and 0.19.1 both die at nim-compile-time with internal errors. Nim-0.19.2 seems to work fine. So, when I next stamp a cligen release, I will actually probably move the nimble version forward to 0.19.2 (which does seem to work). Rather than being able to "back up" the Nim version requirement as you might like, I am sorry to say that I probably have to advance it when I next release cligen.

That said, Nim has a ton of showstopping bugs, moves fast, and shifts the landscape, and I kind of feel like most serious users are aware of that. 0.19.0 is kind of n-2 and 0.19.2 n-1, and 0.19.9 is current (or maybe and devel tip is current) for a more liberal interpretation of "n". when compiles can help with backward compatibility (and I've used that in the past for Nim stdlib API changes). Internal error bombs are a much bigger pain to deal with.

I cannot speak for your downstream users, but I doubt maintaining support for Nim versions prior to 0.19.0 (or maybe even 0.19.2) is very worthwhile. I think with Nim, "n-1" is already somewhat ambitious, though as with all such things, sometimes transitions are more "breaking" than others. That Nim 0.18.x to 0.19.x "not-nil" was a big transition..for Nim, for cligen, and probably for your end users.

Personally, I usually work off pretty recent Nim devel snapshots (days old to a week old). You are the first person I recall asking for support of an almost year old version of Nim. It's more typically been "things fail with the bleeding edge not yet released compiler".

Sorry again for the bad news, but I did look into it a bunch. I wasn't even aware my current devel would fail on <0.19.2.

genotrance commented 5 years ago

Thanks for taking the time to investigate and I appreciate the challenge. However, considering cligen is very popular, I will recommend trying as much as possible to support upto n-2. It will help push Nim to make such compatibility easier as well as inspire the community to appreciate stability.

Most normal users don't live on the bleeding edge and as we approach 1.0, extended stability will become crucial for Nim's overall success.

c-blake commented 5 years ago

I already try as much as I feel is reasonable. It usually works for n-MANY. All n are not the same, though. So, I think your n-2 rule is a bit over-simplified. The particular time you were asking there was a big transition, as explained. Anyway, thanks for the feedback. I will try to keep my nimble requirements as early-versioned as seem to work.