Hi all,
I am considering using Nim as the language of choice to productionalize certain components of a model at my company. To do that however I have to figure out how to set up a private nimble package list/index so I can publish and maintain proprietary libraries without the public having any access to the components. Are there any guides or documentations that can show me how to set the private package list up and force nimble to publish there instead? I know I can probably jury-rig a solution by specifying dependencies using git repo links/commit hash in .nimble but I would much prefer a more formal and streamlined solution similar to a private pip index.
Thanks and apologies if the answer is obvious. I promise I looked but probably didn't do it very carefully.
With nimble you can also install from a private repo, using the url instead of the package name (and you would put the url in the nimble file as dependency). No need to publish stuff.
Another option is nifty that maybe can be adapted to your use case: https://github.com/h3rald/nifty
@pietroppeter
With nimble you can also install from a private repo, using the url instead of the package name (and you would put the url in the nimble file as dependency).
Yep this is basically what I ended up doing. The only thing that slightly annoys me right now is I have to manually git tag the release version to the master branch commit, which I'm sure I can automate fairly easily with a simple script in the CI/CD pipeline anyway.
@PMunch
Not 100% sure how Nimble fetches the packages though, so if they are private repos requiring authentication you might run into some trouble.
Yeah this is exactly the problem I have trying to set it up right now. Nimble can't download the actual packages.json from the alternative package index because it's gated inside a private company repository. I guess I can expose the packages.json somewhere that's publicly accessible but that also means the public has access to at least the list of our internal libraries, their names and private repository URLs etc which I am really not a fan of. I think I will stick with the direct repo link method for now.
Yep this is basically what I ended up doing. The only thing that slightly annoys me right now is I have to manually git tag the release version to the master branch commit, which I'm sure I can automate fairly easily with a simple script in the CI/CD pipeline anyway.
Huh? Are you after installing the #head of your package? You can do that via nimble install url@#head
Actually no. I want to be able to do ranged version requirements eg requires "my_library_repo_url >= 0.1.0 inside my .nimble files. AFAIK this requires me to tag the master branch commits with the associated version numbers otherwise nimble won't know which commit to pull based on the version specification alone.
Works fine when I do though and seems to be simple enough as it is even without full automation. Sure be pretty easy to automate anyway.