[MNT] PEP 508 environment markers for estimators

[fkiraly]

This PR adds functionality for adding PEP 508 environment markers for specifying estimator dependencies.

This is useful to specify operating systems with which the estimator is not compatible, e.g., platform_system!="Windows".
The information is added as a string-valued tag env_marker, which must be PEP 508 compliant.

The logic is tied into _check_estimator_deps, so estimators marked with operating system excludes will not be tested on the respective operating system, and will raise a user friendly error message pointing to its requirements.

Minor change: moved default values for all current packaging tags related to the env up to the BaseObject. Later we could move this into scikit-base.

FYI @ianspektor, @achoum, @yarnabrina, this would allow us to release the temporian transformer with a tag that excludes windows operating systems, and we can delay the fix of the windows related issue to after the next sktime release. What do you think?

[yarnabrina]

I like the idea, but not exactly following how will we use it. Can you please share some details?

[fkiraly]

I like the idea, but not exactly following how will we use it. Can you please share some details?

Situation: suppose an estimator is not compatible with a specific OS, e.g., windows. Like the current temporian one.

Solution: add the tag env_marker='platform_sys!="Windows"'. This solves the issue since (a) the estimator is not tested on windows VM, and (b) windows users will receive a message that this estimator is not compatible with windows.

[ianspektor]

This is awesome @fkiraly, thank you. Would love to get the transformer merged w/o it depending on the windows fix (that we will address asap anyway).

[yarnabrina]

I like the idea, but not exactly following how will we use it. Can you please share some details?

Situation: suppose an estimator is not compatible with a specific OS, e.g., windows. Like the current temporian one.

Solution: add the tag env_marker='platform_sys!="Windows"'. This solves the issue since (a) the estimator is not tested on windows VM, and (b) windows users will receive a message that this estimator is not compatible with windows.

Understood. Yes it makes sense, but just wondering if it's enough to add these markers in the pyproject.toml or not.

For example, suppose we add a marker for temporian that windows is not supported as of now with the upper bound version that we use. Then with an estimator tag users can not use thia transformer on windows until next release of sktime, even if @ianspektor fixes the issue and makes a new release of temporian.

In a lot cases we have seen that dependabot does not behave as expected or completely fail to detect new versions, plus even if it does users won't get it until one more month for next sktime patch/minor release. But if we add the tag just in pyproject.toml, CI will be happy in the meanwhile and users can start using on temporian if a new version is released with the fix.

(Just to be clear, I'm not opposing the tag, I'm just trying to think of possible strict restrictions that may be imposed on users if a check is added to disablean estimator on a OS based on these tags. If it's just for informing users that it's ot well tested on this OS, then I've no feedbacks.)

[fkiraly]

I see - perhaps it's better than if we add the temporian restriction in pyproject for the current release, and discuss how we manage estimator level dependencies, separately?

For temporian, using pyproject for now makes sense, since there is only a single dependent object/estimator.

[ianspektor]

We're fine with whatever makes it easy for you guys 👍🏼 I see you release ~once a month so even if it's not ideal I wouldn't worry too much about users having to wait for an sktime release once we've fixed the issue (just my 2 cents, I think the arguments for going with the pyproject make sense).