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

Allow repeating/overriding options when creating images #80

Closed
Phantop opened this issue Apr 15, 2022 · 3 comments
Closed

Allow repeating/overriding options when creating images #80

Phantop opened this issue Apr 15, 2022 · 3 comments
Labels
wontfix This will not be worked on

Comments

@Phantop
Copy link

Phantop commented Apr 15, 2022

This issue is specifically with the lookback option -B, however it is possible it applies to other user-supplied options. I just have not tried with anything else.

Essentially, my appdwarf project sets a default lookback level higher than the builtin default for mkdwarfs. However, I want to keep the option to change that setting.

If I handled this lazily, a possible commandline would look something like mkdwarfs -B5 -i in -o out -B10, if the user chose to override my default to 10. Currently, this throws this error:

error: option '--max-lookback-blocks' cannot be specified more than once

If this behavior could be changed so that repeat options are accepted and override previous ones, it would be very appreciated.

@mhx
Copy link
Owner

mhx commented Apr 20, 2022

Mmmh, I understand where you're coming from, but... most of the time, this error can be quite useful, telling you that there's an inconsistency in the options you provided. My gut feeling is that the best solution here would be to parse the user input and handle -B (and other options where you want to provide different defaults) explicitly (in your project, that is).

This error is actually the default behaviour of Boost Program Options and I'm not entirely sure if this can be easily changed. I'd rather not make the code more complex for a single use case and at the same time take away useful error reporting.

So, I (subjectively) don't think this change would make a lot of sense. Feel free to convince me otherwise, but I might just close this one unless I can think of a compelling reason not to. :)

@Phantop
Copy link
Author

Phantop commented Apr 20, 2022

I can see that justification but from my perspective I feel like quite a few CLI utilities I have used support multiple arguments in that manner. Just off the top of my head zstd certainly works that way, and if I run it with options like -18 -2 it will focus on the latter argument and use compression level 2.

Can't quite remember how most other programs respond to a situation like this but something in me says that what dwarfs does isn't the typical case. I might be wrong, and it's ultimately up to you regardless. I have a way to handle the argument anyways.

@mhx mhx added the wontfix This will not be worked on label Oct 29, 2022
@mhx
Copy link
Owner

mhx commented Oct 29, 2022

Spent some more time looking into how this could be made to work. Long story short: it's a massive PITA. As I said before, this is more of a philosophical argument rather than a real bug and I'm personally leaning towards the behaviour that errors if you're potentially doing something silly. So I'm going to close this as wontfix.

@mhx mhx closed this as completed Oct 29, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
wontfix This will not be worked on
Projects
None yet
Development

No branches or pull requests

2 participants