Bug: As of WordPress 6.0, can no longer longer deploy if `preferred-install` is `source`
rkaiser0324 opened this issue · comments
Terms
- I have read the guidelines for Contributing to Roots Projects
- This request is not a duplicate of an existing issue
- I have read the docs and followed them (if applicable)
- I have seached the Roots Discourse for answers and followed them (if applicable)
- This is not a personal support request that should be posted on the Roots Discourse community
Description
What's wrong?
In all previous WordPress versions, you were able to set up a Bedrock project even if the root composer config.preferred-install = "source". During development, for example, that is a preferable setting as it allows for easier debugging by leveraging the source control.
As of the update to support WordPress 6.0, however, it only works if preferred-install = "dist". If you set it to source, you end up with web/wp/ containing only composer.json, not the rest of WordPress.
What have you tried?
I think this started with WordPress 6.0; deploying Bedrock with 5.9.x is OK, although I will note that I was using earlier versions of composer/installers and some other dependencies so if those were the culprits it may have broken earlier.
What insights have you gained?
I suspect this happens because https://github.com/roots/wordpress-no-content/blob/main/composer.json only contains a "dist" key.
Possible solutions
config.preferred-install = "source" should be supported.
Since I can't see how bumping the WordPress version should be relevant to this deployment issue, I am logging this issue here. However it's possible it should be the root cause is actually in one of the dependencies; e.g., https://github.com/roots/wordpress-no-content, https://github.com/roots/wordpress-core-installer etc.
Temporary workarounds
Not aware of any.
Steps To Reproduce
- git checkout
roots/bedrock. - Set config.preferred-install to "source" in the root composer.json
- composer install
- Check the contents of
web/wp- only composer.json
I am using composer v2.2.3. I don't have Subversion installed, only Git.
Expected Behavior
web/wp should contain the WordPress source.
Actual Behavior
web/wp/ only contains composer.json.
Relevant Log Output
[app-php8 root:/var/www] $ git clone https://github.com/roots/bedrock.git
Cloning into 'bedrock'...
remote: Enumerating objects: 2341, done.
remote: Counting objects: 100% (20/20), done.
remote: Compressing objects: 100% (20/20), done.
remote: Total 2341 (delta 5), reused 9 (delta 0), pack-reused 2321
Receiving objects: 100% (2341/2341), 773.91 KiB | 0 bytes/s, done.
Resolving deltas: 100% (1189/1189), done.
[app-php8 root:/var/www] $ cd bedrock/
[app-php8 root:/var/www/bedrock] $ composer install
Installing dependencies from lock file (including require-dev)
Verifying lock file contents can be installed on current platform.
Package operations: 18 installs, 0 updates, 0 removals
Failed to download wpackagist-theme/twentytwentytwo from source: svn was not found in your PATH, skipping source download
Now trying to download from dist
- Installing roots/wordpress-core-installer (1.100.0): Cloning 73f8488e51
- Installing composer/installers (v2.1.0): Cloning 75e5ef0543
- Installing symfony/polyfill-ctype (v1.24.0): Cloning 30885182c9
- Installing oscarotero/env (v2.1.0): Cloning 0da22cadc6
- Installing roave/security-advisories (dev-latest bac54e1)
- Installing roots/bedrock-autoloader (1.0.4): Cloning f508348a33
- Installing roots/bedrock-disallow-indexing (2.0.0): Cloning 6c28192e17
- Installing roots/wordpress-no-content (6.0): Cloning e835336a33
- Installing roots/wordpress (6.0.0)
- Installing roots/wp-config (1.0.0): Cloning 37c3823079
- Installing roots/wp-password-bcrypt (1.1.0): Cloning 15f0d8919f
- Installing squizlabs/php_codesniffer (3.6.2): Cloning 5e4e71592f
- Installing symfony/polyfill-php80 (v1.24.0): Cloning 57b712b08e
- Installing symfony/polyfill-mbstring (v1.24.0): Cloning 0abb51d2f1
- Installing phpoption/phpoption (1.8.1): Cloning eab7a0df01
- Installing graham-campbell/result-type (v1.0.4): Cloning 0690bde053
- Installing vlucas/phpdotenv (v5.4.1): Cloning 264dce589e
- Installing wpackagist-theme/twentytwentytwo (1.2): Extracting archive
Generating optimized autoload files
14 packages you are using are looking for funding.
Use the `composer fund` command to find out more!
[app-php8 root:/var/www/bedrock] $ composer --version
Composer version 2.2.3 2021-12-31 12:18:53Versions
2762d0a1961d942a9272155a8866b994f6af2c2c - CentOS 7.7, PHP 8.0.x
As a workaround, config.preferred-install can also be an object: https://getcomposer.org/doc/06-config.md#preferred-install where you could set roots/wordpress to be be dist, and have a wildcard entry to set everything else as source
@dotsam that workaround does the job, although you actually do roots/wordpress-no-content instead:
"preferred-install": {
"roots/wordpress-no-content": "dist",
"*": "source"
},Since not supporting source out of the box is new behavior as of WP 6.0 I think it should be noted in the README. I will open a PR to mention that.
Thanks for the docs update.
@LeoColomb is this something we can support or fix?
@swalkinshaw This is quite a tricky one (but nice catch @rkaiser0324! 👍)
The main concern is the absence of repo/source for no-content variant on which the package can be based on. Fallback to full is possible, but somewhat misleading.
Then for the full variant I guess we can manage with https://github.com/WordPress/WordPress and the appropriate tags, but there is nothing for beta/RC. Fallback to dev is possible, but not very satisfying, and misleading as well...
What do you think? @swalkinshaw
And what do you exactly expect to get as "source" during install, @rkaiser0324?
(Is it possible to transfer this issue to roots/wordpress as well @swalkinshaw?)
Issue transferred 👍
For reference, here's what Composer says about them (though it's what you'd expect):
Dist: The dist is a packaged version of the package data. Usually a released version, usually a stable release.
Source: The source is used for development. This will usually originate from a source code repository, such as git. You can fetch this when you want to modify the downloaded package.
Packages can supply either of these, or even both. Depending on certain factors, such as user-supplied options and stability of the package, one will be preferred.
Related to @LeoColomb's good questions, it gets more confusing when you want to combine source with a stable version like 6.0.0, or dist with dev-main. What would the expectations be in those cases?
Would someone expect the source of a specific tag/ref? Or just always master?
Would someone expect the source of a specific tag/ref?
Actually yes, it usually use a reference (commit or tag) provided with the source attribute.
It is expected in the way that switching preferred-install between source or dist should provide the exact same content but one with the complete git context (from where you can checkout something else and do your stuff).
Here for example monolog/monolog from the API:
{
"version": "3.0.0",
"source": {
"url": "https://github.com/Seldaek/monolog.git",
"type": "git",
"reference": "60ad5183b5e5d6c9d4047e9f3072d36071dcc161"
},
"dist": {
"url": "https://api.github.com/repos/Seldaek/monolog/zipball/60ad5183b5e5d6c9d4047e9f3072d36071dcc161",
"type": "zip",
"shasum": "",
"reference": "60ad5183b5e5d6c9d4047e9f3072d36071dcc161"
},
...
}It is expected in the way that switching preferred-install between source or dist should provide the exact same content but one with the complete git context
Agreed it should provide the same "version" but I don't know about "exact same content". Personally I wouldn't expect the source to be identical to a distributed package plus the VCS metadata. Dist output is usually the result of a "release" process which could do a lot of transformations to the source? Like stripping out debug information, or compiling it differently, etc.
I agree that going from "no-content" to "content" stretches that a bit though 🤔