You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
First of all, this is a really cool project, and I am enjoying it a lot 👍 .
This might be quite niche to be honest, but I encountered unexpected behavior when working on nested classes.
In my use case, the user can choose from multiple loss classes (Strategy in the example), which on their own have another nested dependency injection (NestedStrategy).
Furthermore, some arguments of the loss are linked to (StrategyParameter) and the nested strategy has also arguments provided from somewhere else (NestedParameter).
Now in this setting I found that the instantiation order induced by the topological sort of the dependency graph does not enforce that NestedParameter is instantiated before Strategy.
But when instantiating the Strategy object, all actions which target the nested strategy are triggered too.
So in particular the link
is triggered however before NestedStrategy was instantiated and so the compute_fn is called with the Namespace object.
I am not sure whether the graph should contain the dependency or the instantiation logic should not instantiate the actions leading to the nested class?
In ActionLink.apply_instantiation_links there is this predicate is_nested_instantiation_link (returning False) which hints at the second case being true?
This is how the dependency graph looks like as constructed in ActionLink.instantiation_order:
I tried to keep the example as small as possible.
We have two dependency injected classes Strategy and NestedStrategy and two objects which are used for linking StrategyParameter and NestedParameter.
ValueError: Call to compute_fn of link 'compute_fn(nested_param) --> root.strategy.init_args.nested.init_args.nested_param' with args (Namespace(something_else='Something Else')) failed: Got wrong type. Expected NestedParameter but got <class 'jsonargparse._namespace.Namespace'>
Expected behavior
The NestedParameter class is instantiated before passed as parameter to the compute_fn.
Note, the compute_fn is only to showcase the problem but not necessary to reproduce the bug.
Environment
jsonargparse version: jsonargparse 4.34.0
Python version: Python 3.10.14
How jsonargparse was installed: pip
OS: macOS
The text was updated successfully, but these errors were encountered:
🐛 Bug report
First of all, this is a really cool project, and I am enjoying it a lot 👍 .
This might be quite niche to be honest, but I encountered unexpected behavior when working on nested classes.
In my use case, the user can choose from multiple loss classes (
Strategy
in the example), which on their own have another nested dependency injection (NestedStrategy
).Furthermore, some arguments of the loss are linked to (
StrategyParameter
) and the nested strategy has also arguments provided from somewhere else (NestedParameter
).Now in this setting I found that the instantiation order induced by the topological sort of the dependency graph does not enforce that
NestedParameter
is instantiated beforeStrategy
.But when instantiating the
Strategy
object, all actions which target the nested strategy are triggered too.So in particular the link
is triggered however before
NestedStrategy
was instantiated and so the compute_fn is called with theNamespace
object.I am not sure whether the graph should contain the dependency or the instantiation logic should not instantiate the actions leading to the nested class?
In
ActionLink.apply_instantiation_links
there is this predicateis_nested_instantiation_link
(returning False) which hints at the second case being true?This is how the dependency graph looks like as constructed in
ActionLink.instantiation_order
:To reproduce
I tried to keep the example as small as possible.
We have two dependency injected classes
Strategy
andNestedStrategy
and two objects which are used for linkingStrategyParameter
andNestedParameter
.Output
Expected behavior
The
NestedParameter
class is instantiated before passed as parameter to thecompute_fn
.Note, the
compute_fn
is only to showcase the problem but not necessary to reproduce the bug.Environment
The text was updated successfully, but these errors were encountered: