Offer a laravel/valet local environment instead of Vagrant

[neilgilmour]

Trellis is awesome for provisioning and deploying Bedrock sites, and it would be great to have an easy way to use laravel/valet as a local environment instead of Vagrant.

[swalkinshaw]

@codepuncher @tangrufus any ideas on the easiest/best way to get this done?

[codepuncher]

Thinking we should leverage https://github.com/aaemnnosttv/wp-cli-valet-command as it doesn't matter what OS you run. As long as either Valet, Valet Linux or Valet WSl are installed on the system, you're good to go. Commands are the same so no issue there.

As for dealing with the Valet drivers, we could ship trellis-cli with our own driver to get things running. The only issue with that is not everyone will follow the same directory structure. Our options are:

• Use 1 driver and force directory names of trellis and site (or similar)
• Use 2 drivers to support directory names of bedrock and site (reason being is that we use bedrock instead of site in our work
• Allow customisation of the directory names with a setup script from trellis new or pass some flags like trellis new projectname --project=valet --bedrock-dir=site and build from a template and store as LocalValetDriver.php in project root

Maintaining our own drivers will make things easier, but I really wouldn't know how many people would use structures that aren't trellis and site or trellis and bedrock. Using option 3 of a custom directory via template also means it could be extended to catch any OS inconsistencies (although I dont think we'd run into that).

@TangRufus mentioned about using custom subcommands e.g. trellis itineris new xxx if there was an easy to use plugin system, but he says that https://github.com/mitchellh/cli would make it difficult to do so. Any thoughts on that @swalkinshaw?

[tangrufus]

One thing we can do with the third party subcommand situation is that:

• require https://github.com/roots/trellis-cli/tree/master/trellis as dependency
• publish the custom command on its own, e.g: $ tangrufus-trellis do-something

The major disadvantage is that the dependency is bundled at build time and won't pick up roots/trellis-cli updates.

[swalkinshaw]

If all we need to do is support a custom bedrock/site dir name + generate a single driver file, that doesn't seem too bad. Correct me if that's wrong though.

I'd probably be okay with supporting those options by default.

[swalkinshaw]

@TangRufus interesting idea. I can think of two possible improvements to that:

1. Separate out the core library without any actual CLI related things. This would only potentially reduce how often there's new versions.
2. I think it might be possible to support trellis tangrufus-do-something <args>. tangrufus-do-something would still need to be a separately compiled external binary. trellis-cli could basically just shell out to that process and pass it the args?

[neilgilmour]

I thought it would look more like trellis provision valet but I don't know if that's possible or not.

[swalkinshaw]

Right now it's trellis provision <env> so that doesn't really fit. It could be trellis provision development --valet though. Or trellis provision development --provider=valet

[codepuncher]

I'll see about putting in a PR using the --provider flag. Guess that also means means other providers could be looked at in future.

[tangrufus]

With #48, we can:

• rename trellis check --> trellis vagrant check
• rename trellis up --> trellis vagrant up
• rename trellis down --> trellis vagrant down
• add trellis valet provision (assume that valet doesn't have a provision subcommand)
• add trellis valet check (assume that valet doesn't have a check subcommand)

trellis valet provision:

1. wp db create
2. wp db check (maybe)
3. trellis valet link

trellis valet check:

1. check wp cli is installed
2. check mysql (or mariadb) is installed
3. check php is installed
4. check valet is installed

What do you think?

---

When we have a solution for the plugin system, we can separate trellis valet and trellis vagrant as their own packages.

[swalkinshaw]

I haven't thought about this enough yet, but I'm wary to move the vagrant commands under a vagrant subcommand. As of right now Trellis still uses officially uses Vagrant in development so I prefer having the default cli setup assume that as well.

What you proposed doesn't really depend on namespacing the Vagrant commands right (other than being slightly confusing)? It doesn't prevent us from just adding all those valet specific ones under valet.

I'm completely fine with having these valet commands built-in for now at least under the subcommand 👍

[Xilonz]

Is an .trellis-cli.yml (config file, like wp-cli.yml) an option? I would prefer that over a longer cli command.

[swalkinshaw]

@Xilonz not yet but we do need one eventually. Just created an issue for it https://github.com/roots/trellis-cli/issues/70

[dsecareanu]

Any updates here? I'm looking at setting up a local Valet environment to manage a WP site built on trellis/bedrock and this would help tremendously.

I've found and will try this (https://github.com/danielroe/trellis-valet-driver) in the meanwhile.

This (https://github.com/aaemnnosttv/wp-cli-valet-command) also seems to have some interesting wp cli implementation for bedrock with valet.

Thanks!

[tangrufus]

@dsecareanu Does https://github.com/roots/trellis-cli/pull/48 help?

[dsecareanu]

Probably :) have to test it out though. Thanks!