nimble
nimble copied to clipboard
nim-lang
Optional dependencies
Optional dependencies are a good way to prevent dependency hell and make packages more modular.
The .nimble file could support traditional (aka required), "recommended" and optional dependencies.
Nimble could install the first two types by default, and provide a flag to skip recommended ones and another one to install both recommended and optional.
At build time, depending on what is available, Nimble could set a define for each dependency e.g. "dep_
Perhaps this could also be used to install additional examples, manuals, test files, utilities...
Related to #482
@dom96 any update on this? https://github.com/FedericoCeratto/nim-httpauth would benefit from it.
Optional dependencies would be a great benefit. Simple example are situations where multiple backends are avaiable for a common interaface, some of them commecial. You don't want to have them all as a forced dependency. DirectX for rendering (no point to install it on Linux). Gurobi for Linear programming (not everybody has $$$). etc
if and when statements are totally a thing in a .nimble file since it's NimScript...
@dom96 httpauth is a good example of a library with multiple backends, and therefore multiple dependencies, where the developer typically wants to use only one.
Encouraging library developers to use forced dependencies by default leads to bloated code, unnecessary dependency conflicts, npm-like security disasters, broken builds due to incompatible or retired libraries. Nim is especially at risk due to the volatile library ecosystem and the use of static linking. And backward-incompatible compiler releases.
My intention wasn't to challenge whether this feature should be implemented, I just want to gather the use cases. I do think it is important even if right now it's relatively low pri.
Another example use case: there might be some requirements that are only required for testing/development of the library, but users of the library don't need them.
Another example use case: there might be some requirements that are only required for testing/development of the library, but users of the library don't need them.
That's basically #482.
I need optional dependencies too.
Now I use nimble task as a workaround.
task prologue, "install prologue":
exec "nimble install prologue >= 0.3.6"
task fsnotify, "install fsnotify":
exec "nimble install fsnotify >= 0.1.0"
task extension, "install all":
exec "nimble prologue"
exec "nimble fsnotify"
I will also use my command tools logue to install these dependencies anywhere.
A hybrid library may have dependencies that are only required for the executable, but not for the library itself. Those dependencies might cause conflicts for users who only require the library.
I use...
when not defined(release):
requires "... some testing stuff ..."
...with the conceit that eventually a package manager might do the right thing.
To further clarify the use - a developer should be able to list the optional dependencies that can be enabled and disabled across the whole dependency tree without having to read documentation, .nimble files or sources across the whole tree.
E.g. myapplication ==> library 1 --> optional lib 2 ==> lib 3 ==> bulky lib 4 (a thin arrow means optional)
The developer is shown: 2: support USB mug warmer. Requires 3 and 4. and decides not to use the whole subtree. Libs 2, 3, 4 are not used (even if they happen to be in ~/.nimble/pkgs for some reason)