You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Talking to @schlessera in WordCamp Asia, we discussed adding support for Lando. As we don't know if contributors would agree, we first create this issue to ask for feedback.
The idea is not to lock development to using Lando, but to use it as a sort of "progressive enhancement": If you have Lando, you can benefit from it; if not, nothing happens.
Main benefit
Within the same Lando instance, we can play with the wp command under development, and contrast it against the latest stable wp command:
# SSH into the Lando instance
$ lando ssh
# Execute a command against ALPHA# This prints "WP-CLI 2.8.0-alpha"
$ wp --version
# Execute a command against STABLE# This prints "WP-CLI 2.7.1"
$ /usr/local/bin/wp --version
By having this quick feedback, we can have a better idea of how well the code is doing, before/while writing the Behat test.
Advantages
Quick test against alpha and stable wp
The MySql database created by Lando can be used to run the Behat tests, thus removing the manual step (eg: file startdb shared by Alain)
Drawbacks
We don't want to force contributors to using Lando, so this development may only be available to a subset of contributors
Lando is based on Docker, which is now a commercial tool
In order to keep this process in a single contained file, these commands can be stored in composer.json, and executed via Composer scripts "build-server" (the first time the Lando server is built) and "init-server" (to initialize it from then on). The logic can be stored in .sh files placed in a lando folder
The text was updated successfully, but these errors were encountered:
What is the advantage of having the YAML file bundled in wp-cli-dev, vs. something that someone can simply copy from a page?
The disadvantage is that it becomes something we need to "officially" support, to some degree. Given there are numerous development environments out there, I'm not sure what advantage we gain by putting effort towards Lando.
The reasoning behind adding a .lando.yml file to the dev environment was to offer a fast alternative to setting up a development environment.
@leoloso came up with this idea after we spent almost an entire day at the last WordConf Asia 2023 just setting up the wp-cli dev environment of the participants of the wp-cli working group.
The resulting yml file is not that big (sorry I haven't submitted a PR) so supporting it shouldn't be such a hassle. And I'm not sure if we need to "officially" support it since is just for setting up a development environment, not even for developing.
Talking to @schlessera in WordCamp Asia, we discussed adding support for Lando. As we don't know if contributors would agree, we first create this issue to ask for feedback.
The idea is not to lock development to using Lando, but to use it as a sort of "progressive enhancement": If you have Lando, you can benefit from it; if not, nothing happens.
Main benefit
Within the same Lando instance, we can play with the
wp
command under development, and contrast it against the latest stablewp
command:By having this quick feedback, we can have a better idea of how well the code is doing, before/while writing the Behat test.
Advantages
wp
startdb
shared by Alain)Drawbacks
Potential implementation
Place file
.lando.yml
in the root folder:Then WordPress must be installed. That includes:
In order to keep this process in a single contained file, these commands can be stored in
composer.json
, and executed via Composer scripts"build-server"
(the first time the Lando server is built) and"init-server"
(to initialize it from then on). The logic can be stored in.sh
files placed in alando
folderThe text was updated successfully, but these errors were encountered: