Problem/Motivation
I have found the relation between \Drupal\fixture_manipulator\StageFixtureManipulator and \Drupal\package_manager_bypass\Beginner was always very hard for me to understand, especially how the logic around object destruction works and ensuring that `commitChanges()` gets called because the `StageFixtureManipulator` are serialized in state between requests.
@wim leers did some amazing work to make the current logic work but there seems to be no way to make the current system simple and we are still finding edge cases.
Because of this understanding how this works you have to read many places in our code base and I still find it challenging to understand.
Proposed resolution
Remove the need to have StageFixtureManipulator objects serialized in state at all by adding methods to Beginner that just store package versions in state, not objects.
Remaining tasks
Issue fork automatic_updates-3336255
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #2
tedbowworking on an idea
Comment #4
tedbowupdating summary
relating #3325654: Improve the user experience of having your staged update deleted before it was applied because in the summary I explain we just found an edge case there.
Comment #6
tedbowThought of what I think is an even simpler solution. Working on it in 3336255-subscriber-manipulator
Comment #7
tedbowOk I like 3336255-subscriber-manipulator much better.
I still want to self review the new MR but ready for review.
Comment #9
wim leersWent through this in detail, had a few questions, but man … this is SO MUCH BETTER! :D
Much simpler than #3327391: Improve FixtureManipulator DX: validate package name + ensure StageFixtureManipulator is committed + ensure `package_manager_bypass_composer_stager` is not set to FALSE 🤩
Comment #10
tedbowComment #11
wim leersComment #12
tedbowComment #14
wim leersPer https://git.drupalcode.org/project/automatic_updates/-/merge_requests/67..., RTBC'ing merge request 675, which is a nice simplification over merge request 673! 👏
Comment #16
tedbowThanks for the feedback @Wim Leers!