test: use Nimble to manage Nim #222
Conversation
.github/workflows/ci-test.yml
Outdated
| run: | | ||
| curl -O -L -s -S https://github.com/nim-lang/nimble/releases/download/latest/nimble-linux_x64.tar.gz | ||
| tar xvfz nimble-linux_x64.tar.gz | ||
| ./nimble install nim |
There was a problem hiding this comment.
broadly, we should be able to use nimble setup here, which should install a package-local version of nim that nimble test later uses
There was a problem hiding this comment.
Nimble setup worked out https://github.com/status-im/nim-stew/actions/runs/9663859361/job/26657108122
There was a problem hiding this comment.
nimble install [email protected] also worked out when full version tag was specified. Effective Nimble version during test run was however nimble v0.13.1 compiled at 2024-06-25 17:59:37.
https://github.com/status-im/nim-stew/actions/runs/9667227572/job/26668548913
There was a problem hiding this comment.
nimble install [email protected] ended well, but similar situation with older Nim. This time instead of Nim 2.1.1 older Nim 2.0.6 was effectively used to run the tests.
https://github.com/status-im/nim-stew/actions/runs/9667421954/job/26669209430
There was a problem hiding this comment.
What would we like to see here? Personally, I believe the easiest solution would be for Nimble to be capable of installing older versions of Nim. Additionally, we should update older Nim versions by backporting compatibility with newer versions of Nimble. Up to some limit of course.
Example:
Nim 1.6 is the last major.minor version for v1, and its fix versions (e.g., 1.6.20) could be managed by Nimble, which could also handle Nim v2 versions.
This would be beneficial for developers who need to stick with Nim 1.6 for a long time, potentially extending its lifetime by 2+ years. Downside is a growing technical debt when finally moving to Nim 2.0.
If this approach is too complex or slows down innovation, we might consider following the rustc and cargo approach. This involves moving faster through versions and having the same versioning for both the compiler and the package manager. Rust also uses editions to create consistency across many versions. Is there any such promise for Nim major versions?
What are your thoughts @arnetheduck ?
There was a problem hiding this comment.
I've found a discussion on the related topic in "very old high priority" feature request 654 at issues at nimble at minlang. I feel like we would need to start collecting numbers and data points to give sea of opinions clarity they deserve. :)
There was a problem hiding this comment.
I've compiled report about what I am doing. To tidy up and have something presentable for community. https://www.notion.so/Nim-Tooling-Test-Reports-7b25687860ae41afaa2d4f22af8d07f1?pvs=4
What should we do next ? @arnetheduck
There was a problem hiding this comment.
Added Test05 and Test06 to compare download and installation/setup time to the report.
https://github.com/status-im/nim-stew/actions/runs/9696721086/job/26759247385
https://github.com/status-im/nim-stew/actions/runs/9697350737/job/26761290343
| echo "PLATFORM=$PLATFORM" >> $GITHUB_ENV | ||
|
|
||
| ncpu= | ||
| MAKE_CMD="make" |
There was a problem hiding this comment.
these make sections are not needed
There was a problem hiding this comment.
Aren't they needed for Windows ?
Right now this PR is only to test and collect information. In the test report, there is only one passing combination - Test01. When Nimble installs Nim 2.0 and Nimble 0.14.2.
Test PR to understand wether we can reliably use Nimble to manage Nim.