cli
cli copied to clipboard
Specify services/tooling via "lando init"
I've already read https://docs.lando.dev/basics/init.html and know that I can for example do this:
lando init \
--source remote \
--remote-url https://github.com/drupal/drupal.git \
--remote-options="--branch 8.9.x --depth 1" \
--recipe drupal8 \
--webroot ./docroot \
--name d8test \
--option composer_version=2.0.7 \
--option database=mariadb
Which results in this:
name: d8test
recipe: drupal8
config:
webroot: ./docroot
composer_version: 2.0.7
database: mariadb
Can lando init
accept parameters for setting other things, like services
and tooling
? For example, I would like to end up with:
name: d8test
recipe: drupal8
config:
webroot: ./docroot
composer_version: 2.0.7
database: mariadb
services:
appserver:
extras:
- bla bla
- bla bla bla
phpmyadmin:
type: phpmyadmin
hosts: database
tooling:
drush:
service: appserver
cmd: drush --root=/app/docroot --uri=http://d8test.lndo.site
@klonos i dont think so, probably not something we will support in this iteration of lando but could be a cool feature for the future.
Thanks for considering this @pirog 👍
I would like to note that the workaround for this so far has been to be using "template" .lando.yml files, with "placeholders" in them, and then using custom scripts + sed
and the likes to do replacements and copying. Not ideal.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions and please check out this if you are wondering why we auto close issues.
We haven't heard anything here for about a year so we are automatically closing this issue to keep things tidy. If this is in error then please post in this thread and request the issue be reopened!
I think that this is still relevant and worth pursuing.
For parity between command parameters and what gets added to the .lando.yml file, I'd ideally expect things like this:
-
--config database=mariadb
(with the current--option
still working for backwards compatibility of course) to result in this:config: ... database: mariadb
-
--services phpmyadmin.type = phpmyadmin
and--services phpmyadmin.hosts = database
to result in this:services: phpmyadmin: type: phpmyadmin hosts: database
-
--tooling drush.service = appserver
and--tooling drush.cmd = "drush --root=/app/docroot --uri=http://d8test.lndo.site"
to result in this:tooling: drush: service: appserver cmd: drush --root=/app/docroot --uri=http://d8test.lndo.site
We plan on making lando init much more robust with regard to CLI construction of the Landofile but this will almost certainly be part of Lando 4.
On Fri, Jan 14, 2022 at 5:46 PM Greg Netsas @.***> wrote:
I think that this is still relevant and worth pursuing.
For parity between command parameters and what gets added to the .lando.yml file, I'd ideally expect things like this:
- --config database=mariadb (with the current --option still working for backwards compatibility of course) to result in this:
config: ... database: mariadb
- --services phpmyadmin.type = phpmyadmin and --services phpmyadmin.hosts = database to result in this:
services: phpmyadmin: type: phpmyadmin hosts: database
- --tooling drush.service = appserver and --tooling drush.cmd = "drush --root=/app/docroot --uri=http://d8test.lndo.site" to result in this:
tooling: drush: service: appserver cmd: drush --root=/app/docroot --uri=http://d8test.lndo.site
— Reply to this email directly, view it on GitHub https://github.com/lando/cli/issues/210, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAFOFUCIQSZT4NXSXYTVOE3UWCRV7ANCNFSM4UYWEUYQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you were mentioned.Message ID: @.***>
Fair enough 👍🏼 ...thanks for the update @pirog. Still, this issue should remain open, right?
I agree this would be a great feature and this should be re-opened please @pirog
Would really love this feature, or at least a note on the init docs that 'services' currently cannot be applied using init.