Add global --root and --project flags to allow ddev to run in any directory

[markhalliwell]

Is your feature request related to a problem? Please describe.
Remote ddev server

Describe the solution you'd like
The ability to run ddev commands for a specific project without having to know the path of the project, navigating to the project path and then executing command in that directory.

Currently, I'm using a very complicated jq command to extract the approot of a project name. This requires actually installing jq and proxying the commands via the following script (ddev-proxy):

#!/usr/bin/env bash
# ddev-proxy [PROJECT_NAME] [DDEV COMMAND]
DDEV_PROJECT_NAME=$1 && shift
[[ -z "$DDEV_PROJECT_NAME" ]] && echo "A ddev project name must be the first argument provided" && exit 1
DDEV_PROJECT_APPROOT=$(ddev list -j | jq -r ".raw[] | select(.name | contains(\"$DDEV_PROJECT_NAME\")).approot")
[[ -z "$DDEV_PROJECT_APPROOT" || ! -d "$DDEV_PROJECT_APPROOT/.ddev" ]] && echo "Unable to determine the \"$DDEV_PROJECT_NAME\" ddev directory: $DDEV_PROJECT_APPROOT" && exit 1
cd "$DDEV_PROJECT_APPROOT"
ddev $@

This allows me to setup an alias on my local:

alias rddev='ssh 10.10.1.5 "source ~/.profile && ddev-proxy"'

Then I can simply execute the following on my local:

rddev quo describe

What I would prefer, is to not have to proxy the commands via a custom script at all and instead call ddev directly:

alias rddev='ssh 10.10.1.5 ". ~/.profile && ddev --project "'

Describe alternatives you've considered
Clearly, the above technically works... but it's just more work than is necessary to extract the approot and execute a command for that project. It would be nice if this was just supported natively.

Additional context
None

[rfay]

Most ddev commands take the project as the first argument. For example ddev ssh <projectname or ddev start projectname. Some take multiple projects as args. ddev describe <projectname> works.

Does that solve your problem?

[markhalliwell]

Not really, no. Primarily because it has to be the first arg after the command name.

Some of my most frequently used commands don't allow that, specifically because they take their own arguments after the command name:

ddev config
ddev drush
ddev exec

[rfay]

ddev config can never work... because the project doesn't exist yet in most cases. It must be run in the directory where the project is. One could add a --directory arg to it, and that would be useful (rather than forcing the cd)

ddev drush is a custom command, you can make it do anything you want. Simple to add any kind of argument to it.

ddev exec absolutely should have a --project arg, it would really help that.

[markhalliwell]

ddev config can never work

I get what you're saying, but if you already have a project with a name, then it should work just fine (does in my example above).

If you wanted to create a new project (initializing config), then yes, a --directory or perhaps more aptly named --root argument would be the only alternative.

ddev drush is a custom command, you can make it do anything you want. Simple to add any kind of argument to it.

No, because the custom command only exists in a specific project. One would have to first navigate to the project and then run the custom command.

What I'm proposing here is that if a --project option is specified (right after ddev) then ddev looks up the approot for the project and changes directory before continuing. This would allow said custom commands to actually work.

ddev exec absolutely should have a --project arg, it would really help that.

They should all have one. That's the point I'm trying to make.

Choosing which command has this option and which doesn't would be very confusing.

Actually, I can see use cases for both:

• --root - essentially a "cwd" option that allows you to specify which directory ddev should be executed in.
• --project - essentially a shortcut that looks up the approot of an existing project name and uses that as the --root

[rfay]

A global flag is a reasonable thing. I don't see how it would hurt anything, and could really help.

[markhalliwell]

I really think both flags should be added and I think it makes sense to do them at the same time.

[rfay]

This is a great idea. I ran into a technical challenge when trying it out, chicken-and-egg problem of when commands and flags are created. Asked about it in https://stackoverflow.com/questions/61142797/dynamic-creation-of-cobra-commands-based-on-directory-specified-by-flag

[GuySartorelli]

Just came across this when I was starting to implement #4416 (comment) - these are basically two ways of handling the same (or at least a related) problem, and they conflict with each other.

Looks like we have two options here:

1. Implement Allow global shell commands/custom commands to be run from everywhere (not just inside a project) #4416 (comment). It will be up to whoever writes a command to decide whether the --project flag should be used. What's more, that will only be available for global host commands which use the new CanRunGlobally annotation.
2. Implement the flag globally. All host commands are then basically implied as being able to run globally, so the work in feat: allow global host commands to be run from anywhere, for #4416 #5702 would need to be tweaked to just always show all host commands. We could probably also do the same for all global container commands - just let them all be run globally. If there's no --project passed or the value passed in invalid throw an error, but otherwise run the command as though it's run in that project.

1 is obviously easier, and leaves the list of commands when you run ddev help tidier. But it's also a lot less powerful.
2 is more powerful, since you can now run all global commands globally - but it potentially pollutes the ddev help command list with a bunch of commands you only run once in a blue moon or for project types you don't use often, etc.

Happy to do either, but I don't want to start working on it without some input since these options are mutually exclusive.

[rfay]

IIRC this issue is about running a project command from anywhere and providing context to it about the project it's to run in, it's not about global commands. And it's intended for all (project-level) commands, not just custom commands.

[GuySartorelli]

OH! I don't think that would be practical, since you'd have to either parse the flag before the command you're using it with exists (which I don't think is possible), or include all project commands for all projects as though they're global (which would be messy at best and collision hell at best).

That said - I do think doing this for global service commands might have some merit. Do you have any thoughts on that front?

[rfay]

Can you give an example how you'd use it with global commands? I don't immediately understand how that would help, given the work you've already done.

I haven't thought about it carefully, but as fancy as this stuff is I'd be surprised if we couldn't capture the flag processing early. And you'd be the one to do it!

[rfay]

The basic idea behind this feature request is for DDEV go operate like the Drupal CLI drush. drush normally figures out everything it needs from the directory it's in, but you can run it from anywhere with drush -r /path/to/project/root or drush --uri=/some/url for force it to look elsewhere.

[GuySartorelli]

Can you give an example how you'd use it with global commands? I don't immediately understand how that would help, given the work you've already done.

The work I've already done only applies to global host commands - and it doesn't provide any information about projects e.g. through a flag or argument.

This would be a way to a) provide that extra context, and b) allow global service commands to also be used from anywhere - basically the exact same thing this issue is suggesting, except only for global commands, not project-level commands.

That said, if what you want is a flag that gets pre-processed and dynamically sets up the commands for the project named in the flag.... I can try to figure out a way to do that. At worst I'll be able to show why it isn't possible, at best we'll both get a way to do what we're trying to do 👍

[GuySartorelli]

I've created #5863 to tackle this