questions

[timotheecour]

@disruptek

• what's the difference in your packages between tests and testes
  (https://github.com/disruptek/skiplists)
  (EDIT: testes is actually a package, but appears as an empty dir as it's a submodule in packages that depend on testes; whereas tests is a dir of tests)
• in https://github.com/disruptek/dist README it mentions git submodule update --init ., is --recursive also needed?
  I wonder because some dirs are empty after git submodule update --init ., eg dist/criterion, dist/grok, etc (and skiplists has a .gitmodules file)
• skiplists has a submodule criterion, and dist also has a submodule criterion, so you end up with:

dist/criterion
dist/skiplists/criterion

I don't understand where criterion should end up ideally; dist/criterion or dist/skiplists/criterion ?

• readme in https://github.com/disruptek/dist says:

echo "--path=../dist" >> nim.cfg
nim c project.nim

i tried this:
nim r --path:$nim_D/dist --eval:'import gram/gram'
which gives: /dist/gram/gram.nim(19, 8) Error: cannot open file: skiplists
so presumably some other step is needed? do I also need nimble install skiplists or git submodule update --init from inside skiplists ? if so that would defeat the purpose of dist IMO; what's the correct approach here?

• IMO there should be a master branch (or main as github now calls it), and 1.5.1 cannot replace this; one should be able to track master indefinitely to get the latest whereas tracking 1.5.1 would stop tracking the latest as soon as nim 1.6 is released.

design

I like the overall design goal, and it seems similar to what I had in mind with chef proposal, see timotheecour/Nim#117

There are notable differences though (more on that later), in particular the fact that chef would build on top of nimble (or nimph etc), not just on top of git submodule; maybe dist also assumes nimble/nimph, but that wasn't clear at all from dist README, which only mentions git submodule.

dist tooling

one big advantage of a distribution is to avoid duplicating work when it comes to essential functions such as:

• installing required dependencies, updating the distribution, customizing (package manager aspect)
• doc generation (there should be a top-level theindex.html and links to generated docs, maybe using similar approach as in https://github.com/nim-lang/fusion/blob/master/src/fusion/docutils.nim which generates https://nim-lang.github.io/fusion/theindex.html)
• CI (similar to important_packages in nim repo)
• linting, fixing etc
• the tooling code (doc generation etc) for dist itself could be in another package, so that it can developed independently of the package versioniong that dist is tracking (and so that we can use the latest dist_tooling for the dist tracking nim version 1.2 for example)

[disruptek]

@disruptek

• what's the difference in your packages between tests and testes
  (https://github.com/disruptek/skiplists)

What?

• in https://github.com/disruptek/dist README it mentions git submodule update --init ., is --recursive also needed?

No.

I wonder because some dirs are empty after git submodule update --init ., eg dist/criterion, dist/grok, etc (and skiplists has a .gitmodules file)

• skiplists has a submodule criterion, and dist also has a submodule criterion, so you end up with:

dist/criterion
dist/skiplists/criterion

I don't understand where criterion should end up ideally; dist/criterion or dist/skiplists/criterion ?

Doesn't matter.

• readme in https://github.com/disruptek/dist says:

echo "--path=../dist" >> nim.cfg
nim c project.nim

We haven't figured out how we want to do this yet; see the discussions section of the repo.

design

I like the overall design goal, and it seems similar to what I had in mind with chef proposal, see timotheecour/Nim#117

There are notable differences though (more on that later), in particular the fact that chef would build on top of nimble (or nimph etc), not just on top of git submodule; maybe dist also assumes nimble/nimph, but that wasn't clear at all from dist README, which only mentions git submodule.

Yes, because building upon nimble is like building upon quicksand.

dist tooling

one big advantage of a distribution is to avoid duplicating work when it comes to essential functions such as:

• installing required dependencies, updating the distribution, customizing (package manager aspect)
• doc generation (there should be a top-level theindex.html and links to generated docs, maybe using similar approach as in https://github.com/nim-lang/fusion/blob/master/src/fusion/docutils.nim which generates https://nim-lang.github.io/fusion/theindex.html)
• CI (similar to important_packages in nim repo)
• linting, fixing etc

I await your proposals in the discussions.

[disruptek]

See https://github.com/disruptek/gitnim for the tool that manages dist. For some reason the README is not up to date... 🤔