[BUG] why does `TimeXer` have `endogenous_vars` and `exogenous_vars` in `__init__`?

[fkiraly]

why does TimeXer have endogenous_vars and exogenous_vars in __init__?

This feels like a duplication of metadata in v2, or from_dataset in v1.

@PranavBhatP, @phoeenniixx - is this an oversight?

[PranavBhatP]

Yes @fkiraly , if I recall correctly the initial intent to have these "optional" parameters at the model level was so that the user has a clear idea of what is endogenous and exogenous and also because tslib models have similar parameters. But as the D2 module was developed in parallel, this parameter became redundant and was not removed. It can be safely removed now imo, without any breaking change.

or from_dataset in v1.

The v1 version does not have this duplication issue. The duplication exists with v2.

[PranavBhatP]

How about making this a good first issue? The fix is mostly deleting code.

[ahmedkansulum]

@fkiraly and @PranavBhatP

Please I want to work on this.
Thank you

[PranavBhatP]

Go ahead! Feel free to ask questions along the way.

[ahmedkansulum]

Hi all,

Quick note after looking at PR #1997 (Efficient Attention Backend for TimeXer). In that PR, TimeXer v2’s docstring now explicitly documents:

endogenous_vars: Optional[list[str]] – list of endogenous variable names to be used in the model; if None, all historical values for the target variable are used.

For this issue (#2003), my understanding is that in v2 the preferred pattern is to describe features via metadata coming from TslibDataModule (via feature_names, feature_indices, and features mode), rather than via extra feature-name kwargs on the model itself.

To keep things consistent with the v2 design, my plan would be to:

1. Rely on metadata (or small extensions to it) to determine the endogenous/exogenous split inside TimeXer, and
2. Either deprecate the endogenous_vars / exogenous_vars kwargs in TimeXer.__init__ or keep them only as explicit overrides of the metadata (with clearer documentation).

Before I start changing the implementation and the docstring added in #1997, could you please confirm which direction you prefer?

1. Metadata-only configuration – use metadata as the single source of truth for the endogenous/exogenous split (and eventually remove or deprecate the kwargs), or
2. Metadata + explicit override – keep endogenous_vars / exogenous_vars as optional overrides that, when provided, take precedence over metadata (while the default behaviour is fully determined by metadata).

Whichever option you prefer, I’ll make sure to:

• preserve the current semantics (“if endogenous_vars is None, use all historical values for the target variable”),
• base tests on the existing get_test_train_params / test_timexer_v2.py patterns introduced around [ENH] Efficient Attention Backend for TimeXer #1997,
• and keep the changes scoped to TimeXer v2 and its interaction with the v2 metadata layer.

Thanks, and happy to iterate on the approach if you have a different design in mind for v2.

[ahmedkansulum]

@fkiraly and @PranavBhatP

If I can please have your input on the above.

[fkiraly]

@ahmedkansulum, I think option 1 would be better - not overriding or passing twice.

[ahmedkansulum]

@fkiraly This option is noted, and I am currently working on it and would share update shortly.