Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Passing command line arguments to a task #633

Closed
bluenote10 opened this issue Apr 9, 2019 · 18 comments

Comments

@bluenote10
Copy link
Contributor

commented Apr 9, 2019

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

This comment has been minimized.

Copy link
Contributor

commented Jun 2, 2019

I think it's already possible

task dmdm, "dmdm":
    echo paramCount()
    echo paramStr(2)
nimble dmdm --abc
2
--abc
@genotrance

This comment has been minimized.

Copy link
Contributor

commented Jun 2, 2019

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

@binhonglee

This comment has been minimized.

Copy link

commented Jul 19, 2019

@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.

genotrance added a commit to genotrance/nimble that referenced this issue Jul 30, 2019
@jxy

This comment has been minimized.

Copy link
Contributor

commented Aug 19, 2019

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

This comment has been minimized.

Copy link
Contributor

commented Aug 20, 2019

#686 is the fix, I just need to add tests.

@dom96 dom96 closed this in e39c574 Sep 2, 2019

@zajrik

This comment has been minimized.

Copy link

commented Sep 5, 2019

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

@genotrance

This comment has been minimized.

Copy link
Contributor

commented Sep 5, 2019

Just use koch --latest nimble to get this.

@dom96

This comment has been minimized.

Copy link
Member

commented Sep 5, 2019

@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

This comment has been minimized.

Copy link
Contributor

commented Sep 5, 2019

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

This comment has been minimized.

Copy link
Member

commented Sep 5, 2019

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

@zajrik

This comment has been minimized.

Copy link

commented Sep 5, 2019

@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

This comment has been minimized.

Copy link
Contributor

commented Sep 5, 2019

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

This comment has been minimized.

Copy link

commented Sep 5, 2019

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

This comment has been minimized.

Copy link
Contributor

commented Sep 6, 2019

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

This comment has been minimized.

Copy link
Contributor Author

commented Sep 6, 2019

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

This comment has been minimized.

Copy link
Contributor

commented Sep 6, 2019

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

This comment has been minimized.

Copy link
Member

commented Sep 7, 2019

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

This comment has been minimized.

Copy link
Contributor Author

commented Sep 14, 2019

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
7 participants
You can’t perform that action at this time.