Error: Cannot load to/save from a file because this extension is not registered in the extensions dictionary.

[anoduck]

The same problem applies to combining the add_config_path_arg=True with subparsers.

I'm adding as a comment under this issue (rather than a new issue) because under the covers the config flag is added as a nargs="*" option. Let me know if you'd rather I raised as a separate issue.

The following invocation fails with RuntimeError: Unable to determine what function to use in order to load path deploy into a dictionary since the path's extension isn't registered in the extensions_to_loading_fn dictionary. That's because it's trying to parse subcommand as a filename and the extension ("") isn't recognised.

python run.py --config config.yaml subcommand

but this works:

python run.py subcommand --config config.yaml 

Example code:

from dataclasses import dataclass



from simple_parsing import ArgumentParser





@dataclass

class Dummy:

    value: str





parser = ArgumentParser(add_config_path_arg=True)

parser.add_arguments(Dummy, dest="config")

subparsers = parser.add_subparsers()

subcommand = subparsers.add_parser("subcommand")

args = parser.parse_args()

Originally posted by @MartinHowarth in #105

Extension is not registered

Encountered the same error as @MartinHowarth and received the Cannot load to/save from a file because this extension is not registered in the extensions dictionary error. Except, there are no list_fields in the code. Which IMHO would make it a separate issue from #105. Unlike Martin, I toiled with it for several hours to see if I could first fix the issue, and then to see if the error could be reproduced in sample code.

What is worth noting is the appearance of this "bug" is dependent on two things:

1. Importing Classes from other files.
2. How variables are passed to other classes.

Classes from other files (remote classes)

In the example code used for a question concerning subparsers and configuration files in the discussions. The error message was not recieved, but when the exact same sample code was spread across three different files, and required the creation of new classes for each file, the error came to life.

Variation in how variables are passed.

If the entire argument object (prog or cfg) is passed to a remote class (i.e. class in another file), then the error does not occur, but if only the values required to instantiate the remote class are passed the error occurs.

So, if we use the same base of sample source code, the following did not generate the error.

@dataclass
class Belch:
        """Phrases to Belch out."""
        phrase: str = 'Here is some sample text'  # Sample text to belch out.
        times: int = int(4)  # How man times to perform the belch.
        
        def execute(self, prog, cfg):
                Belcher(prog, cfg, self.phrase, self.times)

But, if we extract all the required values from the argument objects, we get the error. Like so:

@dataclass
class Belch:
        """Phrases to Belch out."""
        phrase: str = 'Here is some sample text'  # Sample text to belch out.
        times: int = int(4)  # How man times to perform the belch.
        
        def execute(self, prog, cfg):
                Belcher(self.phrase, self.times, cfg.speaker, cfg.ending, prog.tofile, prog.txtfile)

Now instantiating each argument in the execute function might resolve this, but we have not tested this
yet. Furthermore, why this happens and if this is significant is not known.

The Solution is the same.

As in #105, the solution is the same. If you provide the command/positional argument before the config file path flag --config-file belch.toml, the error does not appear. BUT, if you provide the argument as the help flag --help generates it, the error will appear. So, ensuring the help flag properly generates the order in which commands are provided, might be the key to resolving this issue.