Custom lando file

[elliottpost]

Is it possible to use a custom lando file? I was imagining to use this tool as a nice GUI to replace some of the existing CLI infrastructure I have, but I can't tell if my custom lando files are working here. For example, using PHPStorm/xDebug together is very helpful for local development to add breakpoints and such. Sample lando file attached.

name: {{my-pantheon-site-name}}
recipe: pantheon
config:
  framework: wordpress
  site: {{my-pantheon-site-name}}
  id: {{redactred}}
  xdebug: true

services:
  appserver:
    overrides:
      environment:
        PHP_IDE_CONFIG: "serverName={{my-pantheon-site-name}}.lndo.site"


  # Add a phpmyadmin db frontend
  pma:

    # Use the latest version of phpmyadmin
    type: phpmyadmin

    # The databases you want to look at, this will default to a service called
    # "database"
    #
    # You might want to run `lando info` on your app to see what databases you
    # have available
    hosts:
      - database

# Add in a proxy route to phpmyadmin
proxy:
  pma:
    - pma.{{my-pantheon-site-name}}.lndo.site

[joshkoenig]

Hey Elliot -

Right now the use of custom Lando config is not fully supported. We need to evaluate the need.

Given Localdev's mission to democratize access to WebOps (and Pantheon's workflow), we're not prioritizing the use-case of someone who's already comfortable using the CLI with all the extra power and flexibility it can provide.

it's possible we could work to include this after reaching 1.0. It's also possible that we want to build better PHPStorm/XDebug support out of the box (which would be different than supporting any old Lando config file).

[elliottpost]

Hey @joshkoenig, I certainly understand your point of view. That said, here's why I think supporting a custom lando file should not prevent Localdev from running correctly.

Pantheon is super developer friendly and fairly developer oriented (using git and at minimum SFTP to update plugins, wordpress, etc). Some clients will have a development agency manage their custom web applications; however, they still want to be able to manage plugins and make very basic updates to text files in the account. This might mean, and is true for all the of the Pantheon sites I manage, that while I am the developer responsible for maintaining the majority of their code, the client would prefer if they could also make some small changes themselves without having to go through my team. Localdev could be the answer for that, but currently it is positioned to only support one or the other: developer or someone who needs a GUI.

For example, if a client wants to add a WordPress plugin, one of Pantheon's strengths is its git-based workflow requiring a standard dev -> test -> live approach; however, for clients who struggle to understand the value in that and just want to install a plugin, that's one of Pantheon's biggest drawbacks compared to something like WP Engine or a VPS. By allowing Localdev to work as a GUI for clients who want to perform, without dropping support for a development agency comfortable with the CLI, Pantheon bridges a gap and is a more rounded and easier sell to a client who wants to manage basic components on their site.

[Edit] What I'm suggesting, in short, is that localdev has something like .lando-localdev.yml in the same way you do wp-config-local.php, so that using a custom .lando file doesn't need to be supported per-say, but it can be ignored by Localdev.

[pirog]

So, my two cents here @joshkoenig @elliottpost

In terms of audience: Localdev is meant to democratize access to Pantheon. This means its looking at the MAMP user and less the Vagrant user. One reason why its able to do this pretty cleanly is because Lando also exists and is a better tool for power users. This separation of audience and concerns makes development, roadmapping, maintenance, etc of both projects WAY easier. If we try to duplicate every Lando feature in PLD and every PLD feature in Lando we end up not delivering the right value to the right people, we burn a lot of hours on "duplication" and ultimately nobody wins.

That said, and to dive into the deeper technical consideration here. For more or less the reasons above im not sure it makes sense or is a good idea for PLD to "support" any Landofile. By "support" i mean have PLD do the exact same thing with the Landofile that Lando would do with.

However, i do think it is totally reasonable that PLD "work" regardless of what is in your Landofile. I'm guessing the under-the-hood magic that needs to happen here is for PLD to only use the things in a given Landofile that make sense for its stated goals and for it to ignore everything, this is to say that PLD might use stuff in the Landofile but it does not de-facto support user config there. There could be exceptions to that but it might make more sense to have those end up in pantheon.yml instead of lando.yml.

Either way, i think this expectation makes sense given the audience breakdown between PLD and Lando. You should be able to use both, even simultaneously, with a single Landofile but for all intents and purposes PLD "spins up what it needs" and Lando "spins up what you tell it to".

[joshkoenig]

@elliottpost I'm not sure how I'd see Localdev letting people "get around" the dev > test > live workflow. Can you elaborate on that?

I'm also concerned with magical "partial support" for lando.yml files. That still feels confusing.

Still feels like we need to take the use-cases one by one. From what I can see here, the features are phpmyadmin and xdebug, both of which make a lot of sense to include in future releases.

[pirog]

@elliottpost having thought this through a little more i think the only clean and reliable implementation here is for PLD to basically control its own destiny and effectively ignore the Landofile. This would mean that PLD would work regardless of the landofile but would "control its own destiny" in terms of the features and things it supports or doesnt, presumably through some sort of GUI config page.

[elliottpost]

@joshkoenig - I agree with @pirog here. PLD ignoring lando.yml files would allow PLD to have its own Lando config so that using PLD does not mean any site with an existing Lando config file would break PLD.

@joshkoenig You're right about the "Dev" > "Test" > "Live" barrier. I'm not sure what I was thinking when I discussed this as a way around it, except for possibly having an all-in-one interface with makes adding plugins to Pantheon very simple for non-tech users. (Think GitHub's GUI for git which just has a "sync" button instead of using terms like "push", "pull", "merge", etc).

[joshkoenig]

possibly having an all-in-one interface with makes adding plugins to Pantheon very simple for non-tech users

That's an interesting idea to consider going forward, actually. I wasn't thinking that far outside the box. We've discussed the potential of shortening the workflow for customers in a few ways. Giving non-tech users a way to preview their changes locally and then "push it live" could actually be very powerful.

[pirog]

Circling back around here!

So in the forthcoming 0.6.0 release PLD will be effectively "decoupled" from an app's codebase's Landofile and the apps features will be controlled directly by PLD in a "config" screen for each app in the GUI.

This means for all intents and purposes PLD should be conceptualized as a "separate and distinct" tool from Lando even though PLD heavily uses Lando tech under the hood.

[tripflex]

Yes I just need XDebug and this should be something any developer needs for BASIC DEBUGGING!

[KarinG]

@joshkoenig - I attended your webops webinar yesterday/today - thank you for putting that on! 👍 and I asked the question about localdev replacing a traditional pantheon/lando install.

I just installed localdev to give it a spin and it looks fantastic!

I got to this thread b/c the only thing I couldn't get working was PHPStorm/XDEBUG. Which I did get working on with a 'regular' local Lando install. I'd like to put my two-cents in and ask you to consider supporting at least xdebug:true in the .lando.yml file in future versions of localdev.