BUG: Aliasing parameters in station config file behaves differently since v0.9.0
- Dominant language
- Python
- Stars
- 459
- Forks
- 359
- Avg merge
- 3d 6h
- Merged PRs (30d)
- 73
Description
We have set aliases for *channel* parameters in a station config file. Before v0.9.0, the aliases were assigned to the main instrument, now they are assigned to the specific channel instead.
In the example below, the alias `temp_alias` becomes an attribute of the channel `A`, not `DummyChannelInstrument` as before.
I don't know which behavior is the intended one, but I am reporting it since it breaks code (at least it broke ours) and it wasn't documented in the changelog. Maybe this was the intention of commit de8f90e04886b2871613856d881cfeab04b02faa ? @Dominik-Vogel ?
### Steps to reproduce
1. Write the following in a station configuration file:
```
instruments:
dummy:
driver: qcodes.tests.instrument_mocks
type: DummyChannelInstrument
parameters:
A.temperature:
alias: temp_alias
initial_value: 273.15
```
2. run
```
d = station.load_dummy()
print("d has temp_alias:", hasattr(d, "temp_alias"))
print("d.A has temp_alias:", hasattr(d.A, "temp_alias"))
```
### Output before v0.9.0
```
d has temp_alias: True
d.A has temp_alias: False
```
### Output after v0.9.0
```
d has temp_alias: False
d.A has temp_alias: True
```
### System
Qcodes master @ 00ec65352f2bd71cce607274a64c334c40b51142
Contributor guide
Research direction
Start with the station configuration example and the DummyChannelInstrument behavior described in the report, then inspect commit de8f90e04886b2871613856d881cfeab04b02faa. Determine which object should own the channel alias, reproduce both reported outputs, and update the relevant behavior and changelog once the intended compatibility is decided.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- backend
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100