markers: ensure units stored as string

[kecnry]

Description

This pull request ensures the units in the markers plugin are in string and fixes adding a marker to the spectrum viewer followed by one of the cube viewers. This bug is confirmed to not be present in 3.10.x, so should not need backporting or a changelog entry.

Change log entry

• Is a change log needed? If yes, is it added to CHANGES.rst? If you want to avoid merge conflicts,
  list the proposed change log here for review and add to CHANGES.rst before merge. If no, maintainer
  should add a no-changelog-entry-needed label.

Checklist for package maintainer(s)

This checklist is meant to remind the package maintainer(s) who will review this pull request of some common things to look for. This list is not exhaustive.

• Are two approvals required? Branch protection rule does not check for the second approval. If a second approval is not necessary, please apply the trivial label.
• Do the proposed changes actually accomplish desired goals? Also manually run the affected example notebooks, if necessary.
• Do the proposed changes follow the STScI Style Guides?
• Are tests added/updated as required? If so, do they follow the STScI Style Guides?
• Are docs added/updated as required? If so, do they follow the STScI Style Guides?
• Did the CI pass? If not, are the failures related?
• Is a milestone set? Set this to bugfix milestone if this is a bug fix and needs to be released ASAP; otherwise, set this to the next major release milestone. Bugfix milestone also needs an accompanying backport label.
• After merge, any internal documentations need updating (e.g., JIRA, Innerspace)?

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 88.82%. Comparing base (f4a6889) to head (d45ed5b).

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #3135   +/-   ##
=======================================
  Coverage   88.82%   88.82%           
=======================================
  Files         112      112           
  Lines       17430    17430           
=======================================
  Hits        15482    15482           
  Misses       1948     1948           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[pllim]

So, is it astropy.unit.Unit now? If so, using unit.to_string(format=something) is more explicit. So if you want FITS compliant units, you do to_string(format="fits").

[kecnry]

at this point I just want to ensure that what is stored is a string, is casting not ok for that, do we need to check the type and call to_string if it is a unit object?

[pllim]

just want to ensure that what is stored is a string

Well, what would it be if not a string nor Unit? It can't suddenly be a number, can it?

I think you can cast str(Unit) but you cannot control the format that way. It has a default but I don't remember on top of my head.

[kecnry]

Well, what would it be if not a string nor Unit? It can't suddenly be a number, can it?

Exactly. Since I don't need to override the formatting, I thought str(unit) was cleaner than something like unit.to_string() if isinstance(unit, Unit) else unit, but can do something like that if you think its better.

[pllim]

Can't tell what is better. I guess this works for now if you need something that can cover other data types as well. If a day comes when we must roundtrip back to FITS format or something, we can reconsider.

[pllim]

If this is to fix a bug, do we need a new regression test?

[kecnry]

If this is to fix a bug, do we need a new regression test?

Working on it - it isn't as easy as it might seem because the existing markers test uses a cube in Jy, which does not show this bug, and switching it to the Jy/sr test fixture changes all the other asserts, so I will need to confirm that those are all correct. That said - its hard to cover every possible combination and order of adding markers that could result in any conflicting units, so we may have to just live with line coverage to some extent.

[pllim]

Since adding tests are not easy and the diff looks uncontroversial, I think we can proceed without tests. Thanks!