Open ggb-sw opened 10 months ago
OK, I was a little premature in that at least part of the problem (that of having to duplicate code in multiple nimble files) can be mitigated by putting that code in an external include file (which I have also included common tasks - hence why include rather than import).
The issues of portability and future proofing would still exist.
If you don't mind me asking this, what do you need this for? because there might be a better way to solve your issue, than implementing this.
@penguinite I don't mind you asking at all.
I am writing some code (for my own amusement only) with interdependent modules. Clearly, should I one day decide to release these musings into the wild then the nimble config files should reflect dependencies between the modules, but so long as the modules remain in my own little private zoo of modules then nimble gets confused by references to modules that are not available in the wild. Thus I have to be able to make the dependency references conditional on whether the modules are in my zoo or out in the wild. Thus I am placing lines such as:
if isInstalledPack():
requires "other_module"
So when running within my zoo, isInstalledPack() returns false and the requires statement is ignored, but if the module is ever released into the wild then isInstalledPack() will return true and nimble knows to download "other_module".
Summary
I would like to have the package.nimble file behave differently if it is installed from a repository or running in a local development directory.
Could we have a builtin function in the nimble system libraries that would return
true
orfalse
depending on whether the package is in local development or installed from GitHub or alike?Description
At present I have include the following code in the nimble file, but I do feel it is a bit of a kludge:
The two biggest problems with this are that:
If the isInstalledPack() were a builtin system function for nimble then these problems could be mitigated. The function should be fairly trivial to include but the main point is that the maintenance of the function will be aligned with whatever other development happens with nimble. Also, it would save having to include (and maintain) the same code in every nimble config file since the code would be centralised in the nimble system libraries.
Alternatives
No response
Examples
No response
Backwards Compatibility
No response
Links
No response