Passing command line arguments to a task

[bluenote10]

It would be nice if nimble tasks could be parameterized by the user via the command line. For example: nimble myTask --verbose and the task could handle the --verbose switch.

Not sure if this is already possible, but I couldn't figure out how.

[xmonader]

I think it's already possible

task dmdm, "dmdm":
    echo paramCount()
    echo paramStr(2)

nimble dmdm --abc
2
--abc

[genotrance]

This makes sense for standard tasks like build but for custom tasks, the packager needs to do it themselves like @xmonader says.

[binhonglee]

@genotrance @xmonader I think this is a regression. It used to work on 0.17.2 for me but it doesn't anymore on 0.20.2.

Here's the task code and output of it:

task dmdm, "dmdm":
    echo paramCount()
    for i in countup(0, paramCount(), 1):
        echo paramStr(i)

nimble dmdm --abc
  Executing task dmdm in /home/binhong/wings/wings.nimble
7
/home/binhong/.choosenim/toolchains/nim-0.20.2/bin/nim
e
--hints:off
--verbosity:0
-p:/tmp/nimblecache
/home/binhong/wings/wings_21085.nims
/tmp/nimble_21085.out
dmdm

As you can see --abc is nowhere to be seen. It just ends at dmdm which is the name of the task.

[jxy]

This is really a regression, as it used to work fine as @xmonader 's comment, but lately paramStr gives more entries, and it does this with the extra parameters of the task completely ignored.

[genotrance]

https://github.com/nim-lang/nimble/pull/686 is the fix, I just need to add tests.

[zajrik]

Any insight as to when this will land in a release?

[genotrance]

Just use koch --latest nimble to get this.

[dom96]

@genotrance this instruction might have problems for many (especially if they installed via choosenim): they won't know what koch is or where to find it. The "proper" command is nimble install nimble@#head, but it relies on the fact that you have a working Nimble installed.

[genotrance]

I'd argue nimble install nimble@#head is bad for choosenim which creates shims in ~/.nimble/bin which change when you pick different versions of Nim. If you use the nimble method, it will create a symlink to a fixed version of nimble in the same directory and choosenim will grumble about the symlink every time.

[dom96]

yes, but at least you'll be able to get Nimble installed. :)

[zajrik]

@genotrance I installed Nim manually per https://nim-lang.org/install_windows.html on my current system (same way I had installed it on my old system, I believe, prior to the long break I've taken from Nim). I had heard of choosenim at some point while doing some reading on Nim again before I picked it back up but I forgot about it when the time came to actually reinstall Nim. I do not appear to have koch in my %NIMPATH%\bin. Is this meant to come with Nim when installing manually?

Because I did not install via choosenim, I should be able to safely update Nimble via Nimble itself with nimble install nimble@#head, correct?

[genotrance]

You can do that but make sure the ~/.nimble/bin is earlier in your path than the %NIMPATH%\bin. Else you will still use the old nimble.

You can also get koch with nim c koch in the %NIMPATH% directory.

[zajrik]

Thank you. Reordering my path is no problem. I should ask, though, what would be the recommended way to update nimble from a manual nim install? Should I consider an alternative way to install and upgrade nim? I'm not opposed to just manually dropping in new versions. Not like it will happen frequently.

[genotrance]

I'm an active user of choosenim since I want to make my libraries work across multiple versions of Nim. If that's not your use case, you can just download and install like you are. You could also use something like scoop.

[bluenote10]

Thanks for the fix!

What I had in mind originally: Instead of accessing raw params we could offer some getter function (e.g. getTaskParams()) which automatically strips away the Nimble executable, the arguments going to Nimble, and the task argument itself. In other words, an API that contains only what is relevant for the task, and doesn't require to re-implement the extraction logic in every task.

This would allow to make passing argument to tasks consistent, choosing one of the two common conventions:

• All arguments up to mytask are Nimble arguments, all arguments after mytask are task arguments.
• All arguments up to -- are Nimble arguments, all arguments after -- are task arguments (like npm handles it).

With exposing the raw arguments we may end up with implementations of both conventions and it wouldn't be clear for users which convention a task uses.

[genotrance]

Seems like a good idea. We can add to nimscriptapi.nim and it will be available to nimble files. Only thing is that there is no documentation for nimble specific procs and it doesn't make sense to add this to nimscript either. I'll let @dom96 share his opinion as well.

It should be easy to decipher task args from the first option since they are appended after the task name already.

https://github.com/nim-lang/nimble/blob/master/src/nimblepkg/nimscriptwrapper.nim#L44

[dom96]

Agree with @bluenote10, I've been wanting a Nimble-specific API for this for a while. I think it makes a lot of sense to do it this way.

Personally I would prefer the first convention.

[bluenote10]

Only thing is that there is no documentation for nimble specific procs and it doesn't make sense to add this to nimscript either.

As an alternative to having a getter proc might be to enable this syntax for task definitions:

task hello, "This is a hello task", args:
  echo "Task arguments: ", args

Personally I would prefer the first convention.

Me as well, because it better fits to how nim c -r handles arguments, and making -- mandatory can be tedious.