#55 Parse String[] args commandline parameter #64

Closed
wants to merge 1 commit into
from

Conversation

Projects
None yet
2 participants
@muuki88

muuki88 commented Mar 20, 2013

This is a first implementation. It reuses the parseProperties implementation. The following things are possible

Single boolean parameters

val conf = ConfigFactory.parseArray(Array("-debug"))
conf.getBoolean("debug") // true: boolean

Multiple parameters

val conf = ConfigFactory.parseArray(Array("-foo", "bar", "-debug"))
conf.getString("foo") // bar: String
conf.getBoolean("debug") // true: boolean
@havocp

This comment has been minimized.

Show comment Hide comment
@havocp

havocp Mar 22, 2013

Collaborator

I'm a little worried that too few people would use this API. I asked on twitter for people to tell me if they would.

I think parseArray might be expected to work more like parseMap; a clearer name might be something like parseCommandLineOptions or parseArgs perhaps.

I wonder if it's an issue that this would make a program accept any option ... there's no checking for typos or invalid options.

I do see how it could be useful though, to unify command line options with your overall config and have the command line options be just another way to config.

I haven't reviewed the code yet, I think the first question is just whether we should have this feature, could use feedback from more people.

Collaborator

havocp commented Mar 22, 2013

I'm a little worried that too few people would use this API. I asked on twitter for people to tell me if they would.

I think parseArray might be expected to work more like parseMap; a clearer name might be something like parseCommandLineOptions or parseArgs perhaps.

I wonder if it's an issue that this would make a program accept any option ... there's no checking for typos or invalid options.

I do see how it could be useful though, to unify command line options with your overall config and have the command line options be just another way to config.

I haven't reviewed the code yet, I think the first question is just whether we should have this feature, could use feedback from more people.

@havocp

This comment has been minimized.

Show comment Hide comment
@havocp

havocp Mar 22, 2013

Collaborator

Thanks for your pull request, by the way!

Collaborator

havocp commented Mar 22, 2013

Thanks for your pull request, by the way!

@muuki88

This comment has been minimized.

Show comment Hide comment
@muuki88

muuki88 Mar 23, 2013

a clearer name might be something like parseCommandLineOptions or parseArgs perhaps

Yeah, the name is probably not the best.

I wonder if it's an issue that this would make a program accept any option ... there's no checking for typos or > invalid options.

I must say that I never used the checkValid method, but I thought this would be the way to check the command line args?

I think the first question is just whether we should have this feature, could use feedback from more people

Any suggestions where to post this?

muuki88 commented Mar 23, 2013

a clearer name might be something like parseCommandLineOptions or parseArgs perhaps

Yeah, the name is probably not the best.

I wonder if it's an issue that this would make a program accept any option ... there's no checking for typos or > invalid options.

I must say that I never used the checkValid method, but I thought this would be the way to check the command line args?

I think the first question is just whether we should have this feature, could use feedback from more people

Any suggestions where to post this?

@havocp

This comment has been minimized.

Show comment Hide comment
@havocp

havocp Mar 25, 2013

Collaborator

checkValid() will detect some problems (like wrong-typed values or missing settings) but it allows "unknown" settings.

I posted on twitter asking for feedback. A few people there and via private email said they used various option-parsing libraries and would want to integrate with those. I guess option-parsing libs handle things like "--" and "-?/--help" and so forth. See http://stackoverflow.com/questions/367706/is-there-a-good-command-line-argument-parser-for-java (there are also several for Scala I guess).

Some people did say they liked the idea of converting command line options into config settings.

I'm a little worried about ending up maintaining something as complex as http://svn.apache.org/viewvc/commons/proper/cli/trunk/src/main/java/org/apache/commons/cli/ and not sure where to "draw the line" on that.

Basically, I'd expect to start getting reports and requests for all the features that full command line parser libraries have. But if we wanted this to be that complete, it really should be its own separate library.

So that's kind of my inclination, is that this is a useful thing but it might need to be in its own jar and either be more complete or be based on one of the popular option parser libs.

Collaborator

havocp commented Mar 25, 2013

checkValid() will detect some problems (like wrong-typed values or missing settings) but it allows "unknown" settings.

I posted on twitter asking for feedback. A few people there and via private email said they used various option-parsing libraries and would want to integrate with those. I guess option-parsing libs handle things like "--" and "-?/--help" and so forth. See http://stackoverflow.com/questions/367706/is-there-a-good-command-line-argument-parser-for-java (there are also several for Scala I guess).

Some people did say they liked the idea of converting command line options into config settings.

I'm a little worried about ending up maintaining something as complex as http://svn.apache.org/viewvc/commons/proper/cli/trunk/src/main/java/org/apache/commons/cli/ and not sure where to "draw the line" on that.

Basically, I'd expect to start getting reports and requests for all the features that full command line parser libraries have. But if we wanted this to be that complete, it really should be its own separate library.

So that's kind of my inclination, is that this is a useful thing but it might need to be in its own jar and either be more complete or be based on one of the popular option parser libs.

@muuki88

This comment has been minimized.

Show comment Hide comment
@muuki88

muuki88 Mar 27, 2013

Point taken. I think it would be a really cool enhancement. However it's not useful for everybody.

I will try to integrate a third-party cmd parser in a separate project. As you mentioned, implementing a new one is nonsene, as there are plenty out there (and good ones, I think).

muuki88 commented Mar 27, 2013

Point taken. I think it would be a really cool enhancement. However it's not useful for everybody.

I will try to integrate a third-party cmd parser in a separate project. As you mentioned, implementing a new one is nonsene, as there are plenty out there (and good ones, I think).

@muuki88 muuki88 closed this Mar 27, 2013

@havocp

This comment has been minimized.

Show comment Hide comment
@havocp

havocp Mar 27, 2013

Collaborator

Thanks for understanding - if you need any features in the config lib to support what you're doing, let me know.

Collaborator

havocp commented Mar 27, 2013

Thanks for understanding - if you need any features in the config lib to support what you're doing, let me know.

@muuki88

This comment has been minimized.

Show comment Hide comment
@muuki88

muuki88 Apr 12, 2013

I started a small project to close the gap between commandline arguments and config. https://github.com/muuki88/config4cli

muuki88 commented Apr 12, 2013

I started a small project to close the gap between commandline arguments and config. https://github.com/muuki88/config4cli

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment