Hey there @anivegesana , thanks for posting!

I'll have to look into this bug more closely, but this seems to be related to these lines here: https://github.com/lebrice/SimpleParsing/blob/master/simple_parsing/helpers/serialization/serializable.py#L793-L799.

Just to check, was this config created with the save_dc_types argument to the to_dict function? (

I'll try to look into it, thanks again for posting!

Hey @lebrice, thanks for looking into this!

I actually didn't know whether to file this as a feature request or as a bug report since it is a little bit of both, and I think I might have confused you with an incomplete description of what I wanted/expected.

Parsing of subgroups is working perfectly for me and loading configs from external files is working perfectly for me as well. The problem is that if I load a configuration that uses subgroups from an external file, with or without save_dc_types enabled, I run into either an AssertionError if save_dc_types is disabled or the TypeError from above if it is enabled. It works if I replace the dictionary with the subgroup name, but this is less than ideal since I have no way of making modifications to the arguments within the subgroup. This is the bug part.

Traceback (most recent call last):
  File "run.py", line 39, in <module>
    args = parser.parse_args()
  File "/home/anirudhvegesana/anaconda3/envs/py38/lib/python3.8/argparse.py", line 1768, in parse_args
    args, argv = self.parse_known_args(args, namespace)
  File "/home/anirudhvegesana/anaconda3/envs/py38/lib/python3.8/site-packages/simple_parsing/parsing.py", line 333, in parse_known_args
    self._preprocessing(args=args, namespace=namespace)
  File "/home/anirudhvegesana/anaconda3/envs/py38/lib/python3.8/site-packages/simple_parsing/parsing.py", line 523, in _preprocessing
    wrapped_dataclasses, chosen_subgroups = self._resolve_subgroups(
  File "/home/anirudhvegesana/anaconda3/envs/py38/lib/python3.8/site-packages/simple_parsing/parsing.py", line 651, in _resolve_subgroups
    assert argument_options["default"] is subgroup_field.subgroup_default
AssertionError

In either case, there is no way is specify which subgroup to choose from the config file. This part is more of a feature request. I am fine with if the subgroup is chosen via the _type_ key used by save_dc_types or a new key, like _subgroup_, that is made for this purpose, but I think that adding a feature like this is the most promising way to fix the aforementioned bug.

Since the subgroup selection is not stored directly, I don't expect it to be easy to save the subgroups to configuration files via dump_yaml, but I think having a way to specify them from a file is still convenient regardless.

I can open separate issue for subgroup selection via file if these two ideas turn out to be very different from each other, or if you have other ideas about how to accomplish this.

Thanks a lot @anivegesana , your explanation really helped me to better undestand the issue.

I've been playing around with this a bit, and I think it's more of a bug than a feature request. I don't think that the loading of subgroups from config files is working correctly. I'll hopefully keep you posted on this, please do ping me here if I don't reply soon-ish (within say a week)

Hey @lebrice,

You told me to check in within a week. How is it going and how far along have you gotten in figuring out why config_path and subgroups don't play well with each other?

Hey @anivegesana , thanks for checking in! I've gotten one part of it to work in #284, the _type_ values are correctly being used to choose the type of dataclass to create, and aren't being passed to the constructor anymore (which was causing a TypeError on my end).

As for the rest of it (the AssertionError and TypeError you mention here), I'm not done exploring the issue yet, but it seems to be caused by the assumptions I had when I implemented the subgroups feature:

• The fields are first parsed as regular string arguments with a "choices" corresponding to the keys of the subgroup dict
• Then, the arguments are added for the selected dataclass, and a new round of parsing happens

The issue seems to be with the first assumption, because I'm assuming that the field is first a simple str field, it's a problem for it to already have a default corresponding to a dict.

I'm not done digging on this, but here's a little overview of what I've found so far.

Ok. Good to hear that you are making progress on the issue! Hopefully the other half of the problem isn't that challenging.

Hey @lebrice, I was somewhat blocking on this issue, so I pieced together parts of #284 to create something that was good enough for my specific issue. Continue working on a permanent fix at your leisure. I attached the commit that I am using for my project above.

@lebrice Hi, is there any update ?

@lebrice Hi, is there any update ?

#284 (comment)

Hey @lebrice @anivegesana - is this finally fixed? This would be a much needed improvement for me too.

@dorbala

Hey @lebrice @anivegesana - is this finally fixed? This would be a much needed improvement for me too.

#284 (comment)