Problem/Motivation
While using core from git (core development) I'm getting following deprecation warnings with new 1.10 RC
core8$ php composer.phar -V
Composer version 1.10.0-RC 2020-02-14 15:11:30
core8$ php composer.phar install -o
> Drupal\Composer\Composer::ensureComposerVersion
Loading composer repositories with package information
Installing dependencies (including require-dev) from lock file
Nothing to install or update
Generating optimized autoload files
> Drupal\Core\Composer\Composer::preAutoloadDump
Warning: Ambiguous class resolution, "Drupal\Composer\Plugin\ProjectMessage\Message" was found in both "/Users/alex/dev/sites/drupal8alt.dev/vendor/drupal/core-project-message/Message.php" and "/Users/alex/dev/sites/drupal8alt.dev/composer/Plugin/ProjectMessage/Message.php", the first will be used.
Warning: Ambiguous class resolution, "Drupal\Composer\Plugin\ProjectMessage\MessagePlugin" was found in both "/Users/alex/dev/sites/drupal8alt.dev/vendor/drupal/core-project-message/MessagePlugin.php" and "/Users/alex/dev/sites/drupal8alt.dev/composer/Plugin/ProjectMessage/MessagePlugin.php", the first will be used.
Warning: Ambiguous class resolution, "Drupal\Composer\Plugin\VendorHardening\FileSecurity" was found in both "/Users/alex/dev/sites/drupal8alt.dev/vendor/drupal/core-vendor-hardening/FileSecurity.php" and "/Users/alex/dev/sites/drupal8alt.dev/composer/Plugin/VendorHardening/FileSecurity.php", the first will be used.
Warning: Ambiguous class resolution, "Drupal\Composer\Plugin\VendorHardening\Config" was found in both "/Users/alex/dev/sites/drupal8alt.dev/vendor/drupal/core-vendor-hardening/Config.php" and "/Users/alex/dev/sites/drupal8alt.dev/composer/Plugin/VendorHardening/Config.php", the first will be used.
Warning: Ambiguous class resolution, "Drupal\Composer\Plugin\VendorHardening\VendorHardeningPlugin" was found in both "/Users/alex/dev/sites/drupal8alt.dev/vendor/drupal/core-vendor-hardening/VendorHardeningPlugin.php" and "/Users/alex/dev/sites/drupal8alt.dev/composer/Plugin/VendorHardening/VendorHardeningPlugin.php", the first w...
...
Proposed resolution
Discover incompatibility and fix
Remaining tasks
tbd
User interface changes
no
API changes
no
Data model changes
no
Release notes snippet
Drupal 9.4.4 removed the 'replace' section from core's composer.json for core modules. However, the 'replace' information for core components was accidentally removed at the same time, which resulted in Composer warnings. The 'replace' information for core components has been restored, which should resolve these warnings.
| Comment | File | Size | Author |
|---|---|---|---|
| #61 | 3116405-d101x-61.patch | 5.88 KB | spokje |
| #60 | 3116405-d100x-60.patch | 5.88 KB | spokje |
| #59 | 3116405-d94x-59.patch | 6.07 KB | spokje |
Issue fork drupal-3116405
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
andypostFixed IS with deprecations only
Comment #3
andypostadded command
Comment #4
andypostadded exact version
Comment #5
alexpottI'm guessing you got this by running
composer install -oto create an optimised class loader. This shows us that Drupal\coder and easyrdf/easyrdf need to fix themselves but as far as I can see code doesn't need to do anything.I'm this should be moved the the drupal/coder project for them to fix.
Comment #6
alexpottAh I see core needs to fix this...
Comment #7
andypostComment #8
alexpottSo I think there are three issues here:
Ambiguous class resolutionI think we should only focus on the third issue here and ensure an issue for 2 exists. The easyrdf issue exists already, #3110972: Update easyrdf library to 1.0.0
Ah xpost with #7 so we just have drupal/coder to sort out...
Comment #9
andypostAnd filed coder issue as child #3116414: Prevent composer 1.10 autoload warnings by moving the test files
Comment #10
andypostComment #11
alexpottAh just tested #3075954: Remove duplicate scaffold files it doesn't fix this at all. It's not about the duplicate code it is about the duplicate scaffold files like .htaccess etc..
Comment #12
alexpottAS per #11
Comment #13
andypostAlso about 3) in composer 2.0 https://github.com/composer/composer/pull/8652
Comment #14
mile23I don't see any fails on the Template group locally, but let's try the testbot and see what happens.
I did get PHPUnit 9 deprecation warnings in both tests, but we'll deal with some of that in #3116856: Workaround PHPUnit 8 warnings:
Comment #15
alexpott@mile23 it doesn't fail. You get the following warnings when you use the optimised autoloader. I.e when you a command like
composer install -o. Note as far as I know we never install on DrupalCI using the optimised autoloader so you're not going to see the warning there.Comment #17
alexpottThe warning happens because we have both
which map to the same namespace so when optimising the classloader compsoer has to choose.
Fixing issue summary because it's not showing the important bit for core at all.
Comment #18
mile23Since the issue is scoped for 1.10, it falls a little outside, but the fail in #14 looks like this, which is a real thing that needs its own followup:
Comment #19
andyposthttps://github.com/composer/composer/releases/tag/1.10.0 published
Comment #20
fgmWe also have releated issues about autoloading. This was initially (?) mentioned in https://www.drupal.org/project/coder/issues/3116414
Core-introduced classes affected are:
This causes messages like
Deprecation Notice: Class EasyRdf_Serialiser_JsonLd located in ./vendor/easyrdf/easyrdf/lib/EasyRdf/Serialiser/JsonLd_real.php does not comply with psr-0 autoloading standard. It will not autoload anymore in Composer v2.0. in <project>/vendor/composer/composer/src/Composer/Autoload/ClassMapGenerator.php:201Comment #21
fgmComment #22
greg.1.anderson commentedComposer 2 testing continued in #3126566: Allow Drupal to work with Composer 2
Comment #23
xjmComment #25
greg.1.anderson commentedUpdated title to clarify that the changes in this patch are orthogonal to #3126566: Allow Drupal to work with Composer 2.
Comment #26
alexpottI'm not sure this issue is critical has this is about dealing with warnings generated when using the optimised autoloader whereas #3126566: Allow Drupal to work with Composer 2 is dealing with Composer 2 compatibility (which does feel critical). Tentatively making a major task as even through the system is emitting warnings under these circumstances nothing is actually broken.
Comment #27
daffie commentedComposer 1.10.5 has already been released. See: https://github.com/composer/composer/releases/tag/1.10.5.
Comment #28
sahana _n commentedRerolled patch #14 Please review the patch.
Comment #29
jofitzRerolled Test Only patches from #14.
Leaving status as NW because the (expected) test failures for Composer 2.0 will need to be addressed.
Patches are noticeably larger, mainly due to #3127918: Add funding info in composer.lock - should those changes be excluded from these patches?
Comment #30
hardik_patel_12 commentedComment #31
hardik_patel_12 commentedSolving test case for 1.10.
Comment #32
hardik_patel_12 commentedKindly follow a new patch.
Comment #33
andypostComment #35
andypostComment #36
meenakshig commentedComment #37
mile23I can't repro.
Comment #38
meenakshig commentedComment #39
alexpottSo yeah this issue has been fixed for 9.1.x and 9.2.x - the warnings no longer occur. However, we have a new warning introduced by composer 2.0.9 that was not there in 2.0.8 :(
When I run composer install -o I get
Composer appears to be looking in the wrong location for static site map :(
This does not happen on Composer 1 or Composer 2.0.8 - going to look in the upstream issues.
Comment #40
alexpottOh damn #39 is for all composer installs on 2.0.9 and not just optimised ones.
Comment #41
it-cruI also get some more deprecation warnings from my composer 1 to 2 switch with Drupal core 8.9.13.
Don't know if this is also a problem for Drupal core 9.x.x or higher, but it seems that this breaks my feed imports from aggregator core module. I. don't know why, because I haven't found any usage of easyrdf in aggregator module. But maybe it is only to late...
This was already reported here: https://www.drupal.org/project/drupal/issues/3126566#comment-13555597
Comment #45
rivimeyDropped in to say there is a (new? to me at least) problem in D9.4.4. I don't know if this represents a bug (in the sense something will go wrong) or just that there is a literally duplicate file set - would be helpful to know. It does look like drupal/core-utility has been installed twice, once in web/core/ and once in vendor/. The site has just been updated to D9.4.4 from 9.4.3 using composer.
Comment #46
eduardo morales albertiAny update?
Warnings after update on drupal 9.4.4 and PHP 8.1:
Fatal error:
Comment #47
mile23It's a bit of a boggle why components are in both vendor/ and core/. They should only be in core/.
Did you try removing the vendor directory and then re-installing?
I can't repro.
Comment #48
parisekMy issue is all about outdated composer files in Drupal components https://www.drupal.org/project/drupal/issues/3272110 because I have custom module which has this dependency, but I don't kow why it happens after update to Drupal 9.4.4 (9.4.3 works fine)
@Eduardo Morales Alberti Try debug with "composer why drupal/core-utility"
Comment #49
spokje@parisek: Is the dependency in a composer.json or a *.info.yml, and how is it defined?
Comment #50
mile23The issue is:
Drupal core 9.4.4's core/composer.json removed the 'replace' sections for the components in #3292380: Remove the "replace" section from core/composer.json
9.4.3: https://git.drupalcode.org/project/drupal/-/blob/9.4.3/core/composer.json
9.4.4: https://git.drupalcode.org/project/drupal/-/blob/9.4.4/core/composer.json
This means that we end up using the files in the core directory, while also grabbing the dependencies split off from the monorepo.
The easiest solution for core is to add the replace section back for components and make a new release.
The bestest solution for core is to exclude components from the codebase of drupal/core, and do the full monorepo thing, but we currently don't have quite the QA level for that.
Adding #3272110: Drupal 9 and 10's Drupal\Component composer.json files are totally out of date as related so we get accurate dependencies for the components.
Comment #51
mile23Also this is a bug, because we shouldn't be installing components twice.
Thanks, Composer, for telling us there's a bug. :-)
Comment #53
mile23MR adds the components back to the replace section.
Comment #54
catchAhh that makes sense, overzealous in the other issue.
Comment #55
spokjeComment #56
spokjeComment #57
spokjeComment #58
spokjeLowered version to 9.4.x since there is where the "party" is starting.
Added gazillion patches for gazillion open dev-branches, since each patch differs on the
composer.lockreference-SHA ofdrupal/core.INSTA-EDIT: Just realized this needs a tad more, putting on NW and self-assigning
Comment #59
spokjeComment #60
spokjeComment #61
spokjeComment #62
spokje- Added test-coverage.
-
10.0.xand10.1.xdon't have Componentdrupal/core-bridgeany more.- Recreated gazillion patches for gazillion open dev-branches.
Comment #63
spokjeComment #64
fgmSame issue with drupal/core-utility when depending on https://www.drupal.org/project/drupalextension, which depends on https://github.com/jhedstrom/DrupalDriver which depends on core-utility. The issue is addressed there at https://github.com/jhedstrom/DrupalDriver/issues/249
Comment #65
quietone commentedThis was RTBC'ed by catch and the @Spokje (thank you) made patches for various versions of Drupal. I downloaded that MR (which is against 9.5.x) and the patches and found only expected differences in the versions, such as the reference hash, asm89/stack-core version.
Therefor setting back to RTBC.
Comment #66
alexpottThe fix looks great.
I reproduced the issue locally by:
1. Checking out Drupal 9.4.x
2. Do composer require drupal/core-utility
3. Do composer dump-autoload -o
I can confirm that after step 2 we have two copies of the core-utility code base - one in vendor and one in core. Given that have two codebases that composer can autoload is very confusing and potentially creating odd behaviour (which one would be patched?) I think this is a critical issue.
It's a bit odd that we've used 3116405 to fix a regression introduced by 292380 but the original issue this one was for has been resolved in Drupal 9 and the error is the same so I think fixing this here is okay.
Was going to rtbc but @quietone has beaten me to it so I'll commit... once I've worked out issue credit :)
Comment #67
alexpottCommitted 2561a20 and pushed to 10.1.x. Thanks!
Committed ada3193 and pushed to 10.0.x. Thanks!
Committed 98deec0 and pushed to 9.5.x. Thanks!
Committed 594996c and pushed to 9.4.x. Thanks!
Comment #72
xjmComment #73
xjmFixing the release note; this isn't actually about Composer 1.10 support anymore.