RFC - Restore Subservice export for compatibility#141
Conversation
Add focused reproducers for downstream imports that still expect service-module Subservice enum aliases. The new tests cover services 17, 3, and 5, matching the import errors seen in tmtccmd after the PUS-C rename. These tests currently fail against main and document another compatibility gap beyond the packet and header behavior changes. --- Generated with the help of Codex, GPT-5 Co-Authored-By: Codex GPT-5 <codex@openai.com>
Keep legacy service-module enum imports working during the PUS-C rename transition. This restores aliases in the affected modules so downstream consumers like tmtccmd can continue importing the old names while moving to the new terminology. --- Generated with the help of Codex, GPT-5 Co-Authored-By: Codex GPT-5 <codex@openai.com>
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #141 +/- ##
=======================================
Coverage 99.85% 99.85%
=======================================
Files 43 44 +1
Lines 3534 3543 +9
=======================================
+ Hits 3529 3538 +9
Misses 5 5
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
@robamu keen to hear what you think: fully support older syntax or require consumers to update usages when using the newer version of the package? |
|
Hmm, I am fine with a breaking change, if backwards compatibility would be a huge pain. The subservice scheme is an old PUS A legacy thing after all. Can't really guess how many library users there are that might be annoyed by this, we are actually moving away from PUS. |
Where can I read about this as someone outside the industry who wants to learn more? Thanks! |
|
Hmm, this is all new and not really written down somewhere. We are transitioning to CCSDS spacepackets + custom application specific protocol. In our case, we are using Rust + the PUS is not designed for running component oriented / object oriented software, and it keeps showing. We tailored the standard so much that we pretty much do not use it anymore in its standard form anyway. |
I see, I see... well maybe then this repo can stay as it is and wait for signal from consumers to discover if something is not right.
Is it this? https://github.com/us-irs/spacepackets-rs |
that is thethe rust equivalent of this library. Using |
Oh, I see. Closer to metal, in a sense. Roll out just enough serialization/deserialization as necessary, without implementing the whole protocol.
That's be cool. |
2 participants
I tried to update one of the consuming projects, https://github.com/robamu-org/tmtccmd, and run into test failures of the kind
ImportError: cannot import name 'Subservice' from 'spacepackets.ecss.pus_5_event'Full stacktrace
The reason, as far as I understand, is that with #135 replacing
subservicewithmessage_subtype, theSubserviceexport has been removed.This opens up an interesting question: Should the PUS-C change be a breaking change or a deprecation?
Given the library is not in a stable version yet, according to SemVer, breaking changes are allowed. Still, I tried to implement #135 as a deprecation only. Evidently, I didn't do a enough of a good job.
If deprecation is the way to move, then this PR restores support for
Subservice. There's more work to do, though, because pointing to these changes still has test failures on the constructors.Details
I'm not sure what the best way forward is in relation to the library design and its consumers. Keen to help either way, be that via a deprecation with support for
subserviceor a breaking change that keeps onlymessage_subtypeand require source changes in the consumers.