Problem/Motivation
Now that #3334994: Add new InstalledPackagesList which does not rely on Composer API to get package info means we can use real composer show to determine which packages are installed we have the problem that FixtureManipulator actually won't work for using `composer show`.
#3343768: Benchmark how slow using composer require would be in kernel tests shows that changing all our tests to real composer show and composer require for packages could slow our tests, 5x to 10x we will need to figure out how to deal with the problem in FixtureManipulator.
Steps to reproduce
Proposed resolution
First attempt
Tried to update FixtureManipulator to also update the composer.lock file. It was actually more complicated we also needed to update the vendor directory
We could probably get this to work but it is much more complicated after #3344127: Run `composer validate` after FixtureManipulator commits its changes add FixtureManipulator::validateComposer(). Every time I fixed 1 validation error another popped up
Second attempt
Updating to FixtureManipulator to call real composer commands
This will have less problems with FixtureManipulator::validateComposer() because don't have to worry about editing the internal composer metadata files directly.
It is also easier to understand because you don't need to know how Composer store info internal files like installed.json and installed.php you just need to know about path repos and basic Composer commands.
It should also be less brittle because it does depend on the formats of internal Composer files.
Remaining tasks
User interface changes
API changes
Data model changes
| Comment | File | Size | Author |
|---|---|---|---|
| #29 | 3343827-29-followup.patch | 5.72 KB | wim leers |
| #12 | 3343827-no-validator-changes-test.patch | 9.83 KB | tedbow |
Issue fork automatic_updates-3343827
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 #3
tedbowComment #4
tedbowRough but I think it proves it is possible
Comment #5
wim leersThis hardblocks #3340022: Tighten ComposerPluginsValidator: support only specified version constraint. See #3340022-10: Tighten ComposerPluginsValidator: support only specified version constraint.
This is a critical follow-up to #3334994: Add new InstalledPackagesList which does not rely on Composer API to get package info.
Comment #6
wim leersReviewed. tl;dr: IMHO we should use
composer validate --check-lock --with-dependencies --no-interaction --ansi --no-cache --working-dir=PROJECT_ROOTin both the fixture creator and when committing fixture manipulations.Comment #7
tedbow@Wim Leers thanks for the review
This issue has only updated 1 validator to use `InstalledPackageList`
I think we may be able to bring in the changes to validators we made in this merge request we made in #3334994: Add new InstalledPackagesList which does not rely on Composer API to get package info in before reduced the scope of that issue to not update the validators. In that merge request we still had
\Drupal\package_manager\ComposerInspector::getInstalledPackagesListand I think it was pretty much the same API we shouldn't have to do all that work over again.I may look into do that if I address the other feedback I might unassign myself. But I think using the other MR should save alot of time because those changes already got some review
Comment #8
tedbowI tried to get the changes from the merge request in #7 but it was not so easy. That was on 2.x and other changes have happened since this. I think we should get this current issue in with 1 validator swapped to prove it works and then do other validators in other isssues
Comment #9
tedbowremoving "attempt" since it seems we can do this
Comment #10
wim leersIt's assigned to you, @tedbow, so you're working on this? If you want Kunal, Yash or Omkar to work on this tomorrow, please unassign 😊
Comment #11
tedbowUnassigning myself.
relating the 2 related issues I created. 1 is fixed and #3344127: Run `composer validate` after FixtureManipulator commits its changes can be worked on separately
Comment #12
tedbowUploaded patch without the changes to the validator to test performance changes of just the manipulator changes.
Comment #13
wim leersMerged in latest
3.0.xbecause several commits happened, let's see if this still passes tests.#3344127: Run `composer validate` after FixtureManipulator commits its changes is RTBC. I was going to propose to wait with this one until that one is done, but … there is no conflict at all! 👍
#12: no observable performance impact! 👍
Comment #14
wim leersRe-testing…
Comment #15
wim leersThis hard-blocks #3342227-17: ScaffoldFilePermissionsValidator should use ComposerInspector instead of ComposerUtility and #3337760-25: ComposerPatchesValidator should use ComposerInspector instead of ComposerUtility, as well as in principle all of the other remaining work falling under #3316368: Remove our runtime dependency on composer/composer: remove ComposerUtility.
Comment #17
tedbow@Wim Leers if you want to take on working the new MR when you start your day please do. I am not sure I left it in good enough place where it would be obvious what the next steps are. If it is all nonsense I can take it back when I start tomorrow.
Sorry the code is a bit sloppy(altered drupalci.yml). I wanted to work quickly to see if this approach was feasible at rather than spend days before we figured out it wasn't
But we are down to a few tests failures so I think this approach will work and is better.
Thoughts on some of the remain failures.
install_pathhere alsoSo probably could be fixed the same way
Comment #18
tedbowCreate follow-up #3345222: Optimize Composer calls in FixtureManipulator . We will need a todo in the code
Comment #19
tedbowComment #20
wim leersPushed this forward. AFAICT the failures in both
FixtureManipulatorTestandComposerUtilityTestare caused by the tests checking theinstall_pathfunctionality, because that's whatComposerUtilityuses.So we're in a chicken-egg situation where we would not have to fix these if
install_pathwere just not used anymore (ComposerInspectordoes not!).So I think the easiest solution is to remove
package_manager/tests/fixtures/FixtureUtilityTraitTest/existing_correct_fixtureand update the test to usefake_siteinstead?Comment #21
wim leersAs discussed, @tedbow is tackling
FixtureManipulatorTestright now 😊Weird, locally
ComposerPatchesValidatorTestpasses… but not on DrupalCI 😬
Comment #22
wim leersI think I found the solution for
ComposerPatchesValidatorTestwhile not strengthening rather than weakening test coverage! 🤞 Calling it a day though, so I really hope I'm right 😅 Otherwise, feel free to revert my commits sincebc89d35a, which did make it pass but still has weakened test coverage.Comment #23
tedbowAssigning to @Wim Leers if you want to take a look.
Of the 3 failing testing in https://www.drupal.org/pift-ci-job/2606788. (I did not see later results yet)
If you want to try, you are welcome to otherwise I will give it a try tomorrow.
UPDATE: see results from https://www.drupal.org/pift-ci-job/2607522 that InstalledPackagesListTest is now failing 🤦🏼
Here is commit with just a comment about this https://git.drupalcode.org/project/automatic_updates/-/merge_requests/74... different tests failed on this 1 line.
👋
Comment #24
wim leersThe first test run with
FixtureManipulatorTestgreen is a fact! 🚀🚀🚀Locally, all tests failing on DrupalCI now pass except for:
ComposerUtilityTestandComposerPatchesValidatorTest.Leaving those to @tedbow.
PRETTY PLEASE HAVE THIS COMMITTED by the time I wake up 🥺🥺🥺🥺
Comment #25
wim leersI was wrong in #24 — while I was writing that comment I made
ComposerPatchesValidatorTestpass too 👍 😊Did a quick review of the MR, but definitely don't wait for my +1 to land this monster!
Comment #26
tedbowre #24 @Wim Leers
Assuming this passes tests I am going to commit this. But since I am the one also who do the last work
@Wim Leers
PRETTY PLEASE HAVE REVIEW THE CHANGES SINCE YOUR LAST COMMIT 😜😜😜😜😜😜😜
Beside getting the last tests, passing it has been a lot of comment with todos. the major new part is in OverwriteExistingPackagesValidatorTest look for
// Confirm that meta-package will have an install path that is the same@Wim Leers you also have commit access so you could revert it if need be.
Comment #28
tedbowCommitted. Re #2 back to @Wim Leers
Comment #29
wim leers🚀 I reviewed it, all looks fine! In any case, there cannot be any doubt that this MR is a huge leap forward, and the follow-ups you created for refinements ensure it'll get better still 😊
Attached is a follow-up patch with nits fixed — assigning to @tedbow to review since he already knows this MR inside/out.
Since this MR, kernel tests roughly take ~1 min longer (from ~250 seconds to ~310 seconds), that seems totally reasonable for the added confidence! 😊 #3345639: For test performance: bundle FixtureManipulator's `composer require` + `composer require --dev` calls will narrow that gap further.
Unpostponed:
This means that we should now be able to completely finish #3316368: Remove our runtime dependency on composer/composer: remove ComposerUtility 👍🚀
Comment #31
tedbow@Wim Leers thanks for the clean up patch! Committed
Comment #32
wim leersThis unblocked #3345222: Optimize Composer calls in FixtureManipulator.