Only new behavior is captured, everything else should work per usual.
Nimble recently added the ability to work with project local dependencies. Simply by creating a nimbledeps
directory in the project is sufficient to go into this mode. Once this directory exists, all information that typically goes into ~/.nimble
is stored here, unaffected by any other projects or global changes.
This feature is being extended with a new -l | --local
flag which sets up a project in localdeps mode. For most cases, all it does is creates a nimbledeps
directory if it doesn't already exist.
E.g. nimble -l init
will initialize a project in localdeps mode.
This flag is only useful when initially working with a project or a pre-existing project folder. Once the nimbledeps
folder is setup, the flag is redundant.
The nimble develop pkg
command clones a new project so setting it up in localdeps mode requires some additional code changes.
Using nimble develop -l karax
for example will result in the following actions:
git clone https://github.com/pragmagic/karax karax
cd karax
mkdir nimbledeps
After this, nimble will setup all dependencies in ./karax/nimbledeps
since project is now in localdeps mode.
Larger Nim projects require code changes to dependencies as well. This requires the user to check out each dependency separately in nimble develop
mode.
This workflow can be simplified with a new -d | --deps
flag for nimble develop
which will also set up all dependencies in develop mode.
Running nimble develop -d karax
will result in the following directory structure:
./dotenv/...
./karax/...
./ws/...
The top level project karax
and all its dependencies will be checked out with git clone
at #head
as sibling directories. This also means all requires
statements with version specific information will be only used to identify dependencies but not their actual versions since you develop on #head
.
By default, nimble will use ~/.nimble
and link all packages per usual.
If -l | --local
is also specified, the project and all dependencies will be set up in project local dependency mode.
Running nimble develop -l -d karax
will result in the following directory structure:
./nimbledeps/... # contains all project local nimble metadata
./dotenv/nimbledeps/nimble.nimble-link # links to ../../nimbledeps
./dotenv/...
./karax/nimbledeps/nimble.nimble-link # links to ../../nimbledeps
./karax/...
./ws/nimbledeps/nimble.nimble-link # links to ../../nimbledeps
./ws/...
This enables project isolation and the project and each dependency can be developed while being linked to their dependencies.
Any nimble commands to add/remove dependencies will work the same whether within the parent directory, the top level project ./karax
or in a dependency directory.
Hello @zah, thanks for taking the time to review this.
For #1, I think you already noticed but instead of introducing yet another
nimble.develop
file, I simply reused the.nimble-link
implementation to pointpkg/nimbledeps
to../nimbledeps
. This reduces the amount of new code as well as avoiding yet another file that users need to worry about (gitignore, etc.). Note that if a user does not want to use localdeps mode, it will still work - you will end up with.nimble-link
files stored in~/.nimble/pkgs
and nonimbledeps
directories at all. So it minimizes the changes as well as the user impact.For #2, I had the same concern and most users probably don't need all their deps in develop mode. But if this is the case, it would still be easier to simply do the following instead of adding all the flags proposed in the
nimble.develop
PR.With current shipping behavior, where packages are specified in dep order:
For localdeps mode, we need a subset of the above proposal where we create
nimbledeps
links to the sharednimbledeps
directory.Here, the packages identified would simply be those that the user really wants to develop and other dependencies will end up in the global
~/.nimble
or sharednimbledeps
directory. This would need a changes to nimble'sprocessDeps()
function where any dep identified out of order on the command line will need to be run throughnimble develop
. Without this change, they would end up with a version in $nimbleDir as well as #head checked out. It will work as expect though since #head will take precedence but would be messy.Basically though, if the user needs to be specific about what they want, we don't even need the
-d | --deps
flag I proposed but the user would need to specify what they want.When using
~/.nimble
, nimble already knows where to findws
. For localdeps mode,./karax/nimbledeps/nimble.nimble-link
points to./nimbledeps
which contains a.nimble-link
tows
in./ws
.Adding / removing or converting packages between develop and regular mode would simply use standard nimble calls like
nimble install
,nimble remove
ornimble develop
. They would work whether run in the top level, the main project directory or a dep directory. No additional code is needed or a change in user workflow.Nimble only creates links for develop packages - why is this not sufficient information? Further, the
nimblemeta.json
file also has anisLink: true
value. If needed, we can even extend the metadata to state it is in develop mode.The daily git pull can be discussed separately cause once we have the directory structure, it will just require the addition of some new flag or command like
nimble develop -u
in the top level directory which will then run through all the dependencies or something.