Vendor a copy of Super State Machine #1708
Conversation
| @property | ||
| def actual_state(self): | ||
| """Actual state as `None` or `enum` instance.""" | ||
| attr = self._meta["state_attribute_name"] | ||
| return getattr(self, attr) | ||
|
|
||
| @property | ||
| def as_enum(self): | ||
| """Return actual state as enum.""" | ||
| return self.actual_state |
There was a problem hiding this comment.
Moved these methods here from utils.py and removed the following from _generate_standard_methods:
cls.context.new_methods['actual_state'] = utils.actual_state
cls.context.new_methods['as_enum'] = utils.as_enum
since @property decorators outside of class definitions didn't pass linting checks. (This might cause unnoticed name collisions, but within our restricted usage in Bluesky, it is extremely unlikely.)
|
We should make the vendored version private, we definitly want to be able to switch this out with a different implementation without having to go through a deprecation cycle. https://github.com/pypa/pip/tree/main/src/pip/_vendor is a good reference for how to do this and we probably should follow it here. |
|
It might be worth to make a LICENSE directory and copying the SSM license into a file called LICENSE_SUPER_STATE_MACHINE following something like https://github.com/matplotlib/matplotlib/tree/main/LICENSE |
|
I am very wary of making any changes to the vendored code in this move. The current state runs, any moderization or changes, particularly stylistic ones, run the risk of adding bugs without a huge upside. |
|
I would also prefer that we sush the linters / type checkers rather than fix SSM. |
|
I agree with @tacaswell regarding not making changes to the vendored code in order to appease the linter. There were only a couple of bits related to the compatibility with Python 2 that I removed (and the Also, I might have misunderstood the meaning of |
2b1146a to
0362cdc
Compare
|
Thank you for the suggestions regarding vendoring, @tacaswell! I've used the pip's |
|
Still the library did not have its own testing. Unit testing for the core of bluesky is ideally something exhaustive. I don't feel 100% convinced that vendoring is the optimal long term choice, I am not aware if right now we are running into any limitations with this library. If are not and we can accept the lack of test or write our own that would be not in the library itself, this PR could be merged and the vendored in library code left alone. Should that not be the case, alternatives to 'non-modify-vendoring' in the order of least to most work are:
|
|
Thank you, @stan-dot, for your comments. Yes, I agree that our case for vendoring differs from that of pip's, and actually the use of their I didn't know what to do with the tests. I can certainly just keep their existing tests, but this approach seems to be rather formal -- it would be better to have some sort of integration tests that specifically address the functionality of SSM used in bluesky (and I think we already have a couple). One reason in favour of keeping the existing tests that I can see is checking that SSM works with newer versions of Python. Happy to add them if this makes sense. I personally would be keen to explore options 2, and especially 3, but this definitely would fall out of scope for this sprint/hackathon. |
|
Just looping you in, @danielballan, in case you're interested. |
|
@genematx option 2 (a rewrite) is only 3k lines, so a refactored and tested MVP could be theoretically done with 2 weeks of engineering time |
|
My two cents: Vendor for right now, but prioritize a rewrite in the medium term. I agree @stan-dot that this should not be a heavy lift. |
|
Can we squash this to one commit? |
|
Sure, one commit is easy. Should I just merge it? |
This was previously available as a transitive dependency from bluesky but has now been removed (bluesky/bluesky#1708). This is a temporary workaround to make the build work again and may be reverted if the types are made available from bluesky in future. See #553.
This was previously available as a transitive dependency from bluesky but has now been removed (bluesky/bluesky#1708). This is a temporary workaround to make the build work again and may be reverted if the types are made available from bluesky in future. See #553.
Vendor a copy of Super State Machine into the Bluesky Repository
Description
This PR adds a copy of Super State Machine source code, into the Bluesky repository and removes the external dependency. The automated
vendoringtool was used for this purpose.Motivation and Context
The Super State Machine repo has been updated for more than 7 years, and we would like to use dependencies with good maintenance status. This PR address Issue #1679 .
How Has This Been Tested?