use hashes instead of submodules

[timotheecour]

@disruptek

git submodules

• git submodule update --init works

list of hashes

• you're not tied to what git submodule allows; it's in fact simpler to maintain a list of hashes
• instead of having to maintain 1 branch per nim version as done in dist currently, you can have a single version controlled file that specifies for each nim version a set of hashes that are known to work together. It's far more flexible and easier to maintain without the downsides of git submodule.
• you can attach metadata to each package

In fact this would work much like important_packages.nim, or even brew package manager.

# distkoch.nim:
# thi specifies in a compact way the selected version for each nim version
# eg nim 1.0.x (latest stable in version-1-0) through 1.2.x would use git tag v0.4.8 for bump
# nim devel would use git hash 8d5c706
pkg "bump", "https://github.com/disruptek/bump", ("v10": v0.4.8, "v14": v0.5.2, "devel": 8d5c706)

# in this case, the earliest nim version supported would be 1.2.x
pkg "unicodedb", "https://github.com/nitely/nim-unicodedb", ("v12": 2a5b701)

# metadata can be added
pkg "unicodedb", docCmd = "nimble doc", testCmd = "nim r tests/tmain", srcDir = src

• you just need 1 branch (master), dist can have its own tags/versioning much like any other package (and independently of nim's own versions), and HEAD of master can temporarily break without impacting each release tag of dist
• tooling code added to dist (eg to publish docs in a unified way, run CI, install packages tied to a given nim version etc) can be maintained in a single branch (the main branch) instead of having to be maintained in each of the branches tracking nim versions as currently done in dist

[disruptek]

I don't disagree that what you suggest would work, but you don't make a compelling case for why anyone would want it.

There are a few advantages to the current approach:

• it works
• it lets us deprecate code naturally
• it lets us separate code naturally
• there are synergies to tying submodule to parent by branch name
• there's no tagging to think about
• tooling naturally inherits all of the above

In short, it's not an accident that it works this way. 😆

[Araq]

How about the fact that with git submodules "git checkout " doesn't undo the "changes" to the submodule's hashes according to "git dfif"? But probably that's just me not understanding git submodules... For me git submodules simply never work, whenever I have to use them.

[disruptek]

Will you show me what you mean?