Skip to content

Positional config file arguments do not work when config file arg is not first #265

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

Open
benjamin-fenker opened this issue Mar 4, 2022 · 2 comments · May be fixed by #266
Open

Positional config file arguments do not work when config file arg is not first #265

benjamin-fenker opened this issue Mar 4, 2022 · 2 comments · May be fixed by #266

Comments

@benjamin-fenker
Copy link

Perhaps an odd situation, but if I use positional arguments AND my config file is not the first argument, the file is not opened. For example:

main.py

import configargparse

p = configargparse.get_argument_parser()
p.add_argument("first_argument")
p.add_argument("config", is_config_file=True)
p.add_argument("--option")
arguments = p.parse_known_args() # or parse_args()

print(arguments)

config.ini

option = yes

And execute it with

python main.py first config.ini:

usage: mwe-fails.py [-h] [--option OPTION] first_argument config
mwe-fails.py: error: Unable to open config file: first. Error: No such file or directory

However, if I switch the order of arguments and modify the command appropriately, I get the expected behavior

@benjamin-fenker benjamin-fenker linked a pull request Mar 4, 2022 that will close this issue
@bw2
Copy link
Owner

bw2 commented Jun 27, 2023

If other users have this issue, please post here. My initial sense is that this is a rare / unusual use case.

@tbooth
Copy link

tbooth commented Apr 23, 2025

It does seem an unusual use case, but I had a look at whether this part of the code could be made more elegant. I propose that, rather than creating subordinate argparse objects in a loop to detect config file settings, a single subordinate parser is created. I coded this up and it seems more elegant to me, and has other benefits including fixing this issue.

tbooth@216d723

I'm hoping this can be contributed back into the upstream project.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants