Closed rkaiser0324 closed 2 years ago
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 🤔
Terms
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 onlycomposer.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
roots/bedrock
.web/wp
- only composer.jsonI 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 containscomposer.json
.Relevant Log Output
Versions
2762d0a1961d942a9272155a8866b994f6af2c2c - CentOS 7.7, PHP 8.0.x