Up until now, the little coding I have done with Nim has had all shared code in a single directory, and using a --path=... in the nim.cfg file for the project.
This is clearly not a very scalable (nor particularly idiomatic) solution to sharing code between projects, so I am looking to put the various bits of code into their own local packages. Alas, I am getting a bloody head from continuing to hit it against a brick wall in trying to achieve this, and since you kind fellows out there have been so helpful in the past I thought that while I go to bandage up my head I would graciously ask your help in achieving this.
I am doing this on Linux, so am looking for a Linux solution to this.
I have created a file ~/.config/nimble/nimble.ini
The file contains:
[PackageList]
name = "Local project packages"
path = r"$HOME/Dev/nim-pkgs/packages.json"
I have created a file called $HOME/Dev/nim-pkgs/packages.json. The contents of the file are:
[
{
"name": "run_context",
"url": "./run_context"
}
]
Within $HOME/Dev/nim-pkgs/run_context I have a run_context.nimble file and the source file.
Yet nimble -i list will not list run_context as an installed package.
We had 'nimble develop' but this is kinda broken, unfortunately:
Use this structure:
projects/projectA/module1.nim
projects/projectA/module2.nim
projects/projectB/module3.nim
projects/projectC/module4.nim
projects/nim.cfg # with the --path entries
It "scales", what ever that is supposed to mean for a single developer setup.
I use nimble setup for handling this. Assuming your local packages have a git repo, you might be able to do the same. nimble setup requires a recent nimble, so you might have to update.
Add your package to your .nimble file with requires, pointing to a specific tag or commit (ex. requires "https://github.com/dsrw/model_citizen 0.18.17"), then run nimble setup. This will fetch your dependencies into your ~/.nimble directory and create a nimble.paths file pointing to them. Normally I develop like this, but if I need to work on a dependency I update the path in nimble.paths to my local version and make my changes. When I'm done and have pushed an updated version of my dependency, I change my requires line to the new version, then run nimble setup again. This gets me back on the published version, so if I screwed anything up (forgot to tag, omitted a file, etc) I'll know about it the next time I build. Alternatively you could just leave it permanently pointed to your local copy.
OK, it seems using a higher level nim.cfg that looks down on the various packages is the best solution I can find. It does work well enough.
What would be nice if at some future time the path could take a wildcard parameter - e.g. --path="./project/*"
What would be nice if at some future time the path could take a wildcard parameter - e.g. --path="./project/*"
I love this idea, thanks!