Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

DM-39100 Move PipelineTask Config override handling #329

Merged
merged 3 commits into from May 10, 2023
Merged

Conversation

natelust
Copy link
Contributor

@natelust natelust commented May 9, 2023

Move the handling of PipelineTaskConfig override handling into the Config class and out of the Pipeline. This allows Config classes more control over how overrides are applied, and a place to add a hook to react to config values.

Checklist

  • ran Jenkins
  • added a release note for user-visible changes to doc/changes

@codecov
Copy link

codecov bot commented May 9, 2023

Codecov Report

Patch coverage: 71.87% and project coverage change: +0.01 🎉

Comparison is base (1cb0dfd) 82.12% compared to head (432892e) 82.13%.

❗ Current head 432892e differs from pull request most recent head 9858a02. Consider uploading reports for the commit 9858a02 to get more accurate results

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #329      +/-   ##
==========================================
+ Coverage   82.12%   82.13%   +0.01%     
==========================================
  Files          60       60              
  Lines        6718     6723       +5     
  Branches     1374     1373       -1     
==========================================
+ Hits         5517     5522       +5     
  Misses        923      923              
  Partials      278      278              
Impacted Files Coverage Δ
tests/test_pipeline.py 96.70% <ø> (-0.08%) ⬇️
python/lsst/pipe/base/config.py 66.66% <59.09%> (-2.83%) ⬇️
python/lsst/pipe/base/configOverrides.py 87.77% <100.00%> (-0.27%) ⬇️
python/lsst/pipe/base/pipeline.py 64.53% <100.00%> (+0.89%) ⬆️
tests/test_pipeTools.py 97.22% <100.00%> (+0.02%) ⬆️

... and 1 file with indirect coverage changes

☔ View full report in Codecov by Sentry.
📢 Do you have feedback about the report comment? Let us know in this issue.

@natelust natelust force-pushed the tickets/DM-39100 branch 3 times, most recently from a11ef83 to 63d2f00 Compare May 9, 2023 18:01
@natelust natelust requested a review from TallJimbo May 9, 2023 18:02
Copy link
Member

@TallJimbo TallJimbo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please do add a changelog entry, otherwise looks good.

from numbers import Number
from typing import TYPE_CHECKING, Any, Dict, Optional, Tuple, Type, TypeVar
from typing import TYPE_CHECKING, Any, Dict, Iterable, Optional, Tuple, Type, TypeVar
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
from typing import TYPE_CHECKING, Any, Dict, Iterable, Optional, Tuple, Type, TypeVar
from collections.abc import Iterable
from typing import TYPE_CHECKING, Any, Dict, Optional, Tuple, Type, TypeVar

You don't need to all the way in terms of modernizing type annotations here, but this much should already be consistent with the rest of the module and only involves the new symbol you've imported.

---------
instrument : `Instrument` or `None`
If this is not None, this is an `Instrument` instance which
will be used to apply instrumental overrides.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should just say that this was the Instrument instance referenced by the pipeline, or None if there was no instrument in the pipeline; it's now up to the task to decide whether to apply overrides with it (even if we expect them to almost always apply those overrides).

will be used to apply instrumental overrides.
taskDefaultName : `str`
The default name associated with the `Task` class. This is
used with instrumental overrides.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In keeping with previous comment, maybe say, "This may be used for instrumental overrides."

The default name associated with the `Task` class. This is
used with instrumental overrides.
pipelineConfigs : `Iterable` of `ConfigIR`
This is an iterable of `ConfigIR` objects that contain
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
This is an iterable of `ConfigIR` objects that contain
An iterable of `ConfigIR` objects that contain

if subConfig.python is not None:
overrides.addPythonOverride(subConfig.python)
for key, value in subConfig.rest.items():
overrides.addValueOverride(key, value)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm guessing this is unchanged, but I would not have expected these overrides to be applied after the python: block when both exist, though I don't have a solid reason for that expectation.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Value overrides are always last, as python block have the most side effects, importing things, retargeting, etc

instrument: str
A string containing the fully qualified name of an instrument from
which configs should be loaded and applied
instrument: Instrument
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
instrument: Instrument
instrument : `Instrument`

Move the handling of PipelineTaskConfig override handling into
the Config class and out of the Pipeline. This allows Config
classes more control over how overrides are applied, and a place
to add a hook to react to config values.
Remove the constrain that parameters must be defined in Pipelines,
freeing up task config objects to make use of the info as they
see fit.
@natelust natelust force-pushed the tickets/DM-39100 branch 2 times, most recently from 432892e to ada6f02 Compare May 10, 2023 19:33
@natelust natelust merged commit 3b0cfa4 into main May 10, 2023
7 checks passed
@natelust natelust deleted the tickets/DM-39100 branch May 10, 2023 19:50
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants