nimph 2.0
With Nimble now supporting localdeps, we no longer need to support Nimble. :wink:
This lets us remove most/all callouts to subprocesses, parsing of the packages.json, and ideally, parsing of NimScript. We might embed the compiler for interpreting it, but we won't call out to dump project metadata anymore.
I've learned some things in the last year, so this will be a 2.0 rewrite with breaking API changes. Most of the changes are caused by even tighter "correct by construction" types.
From the perspective of UX, the early changes will be as follows:
- we'll try to work with Nimble, but the stance will be Nimph-first from now on
- we'll use Git submodules for dependencies and intuitive relative import paths
- we'll generate your
nim.cfgand probably theproject.nimbleas well - we'll use hashes in lockfiles, because now there's no reason not to :grin:
- we'll bundle Nimph in https://gitnim.com/ for easy binary distribution; no more build bs
- we'll expose a cache via frosty and a dependency graph via gram for tools
The idea with this last bit is that Nimph can provide an API for tools that won't require the full dynamic library support of SSH, libgit2, and crypto. We'll be able to do simple stuff like change to the directory of dependency foo or dump the dependency tree as a PNG in tiny extensions without having the (relatively complex) Nimph development environment on the user's host.
Future goals of a 2.0 branch will be to provide some kind of TUI for easily upgrading dependencies and/or inspecting the test matrix. I'd like to see CI integration here, probably GitHub only, to start.
Notable technology coming down the pike which we'll be able to leverage includes shallow repositories (from libgit) and a GraphQL library for Nim that we can use for GitHub Actions.
This PR is not ready for consumption; in fact, @Clyybber, if you try to compile it Nim will infinite loop. :laugh:
Check out this concept insanity from running the recent groups.nim (you need to use cpp):
http://ix.io/2v3M
🔵 we start with a simple "collection".
⚫ var g: seq[string]
🔵 add some values.
🟢 g.add "Goats"
🟢 g.add "pigs"
🔵 make an immutable copy.
⚫ let h = g
🔵 a string is a suitable type for tests.
🟢 assert string is Suitable
🔵 g is a Collectable of strings.
🟢 assert g is Collectable[string]
🔵 sure, fine, as expected.
🟢 assert g is Collectable
🔵 ok, great. and this works, for now!
🟢 assert g is Groupable[string]
🔵 this does not -- but why not?
🔴 assert g is Groupable
🔴 🗏 207 assert g is Groupable
🔴 🗇 groups.nim
🔴 🗇 207 assert g is Groupable # in groups()
🔴 🗇 ../../../nims/lib/system/assertions.nim
🔴 🗇 30 cast[Hide](raiseAssert)(msg) # in failedAssertImpl()
🔴 🗇 23 sysFatal(AssertionDefect, msg) # in raiseAssert()
🔴 🗇 ../../../nims/lib/system/fatal.nim
🔴 🗇 49 raise (ref exceptn)(msg: message) # in sysFatal()
🔵 h is immutable, so isn't Groupable[string], right?
🔴 assert h isnot Groupable[string]
🔴 🗏 209 assert h isnot Groupable[string]
🔴 🗇 groups.nim
🔴 🗇 209 assert h isnot Groupable[string] # in groups()
🔴 🗇 ../../../nims/lib/system/assertions.nim
🔴 🗇 30 cast[Hide](raiseAssert)(msg) # in failedAssertImpl()
🔴 🗇 23 sysFatal(AssertionDefect, msg) # in raiseAssert()
🔴 🗇 ../../../nims/lib/system/fatal.nim
🔴 🗇 49 raise (ref exceptn)(msg: message) # in sysFatal()
🔵 if you add `del(w, T)` to the Groupable,
🔵 then g is no longer a Groupable[string]!
🟢 assert g is Groupable[string]