As CLI user, I want the ability to interact with each site from any directory.

[rickmanelius]

PROPOSAL STAGE

What happened (or feature request):

Feature request.

What you expected to happen:

I would like an optional parameter that allows me to target a ddev working directory from any directory. Example: "ddev describe" when within the working directory or "ddev @project describe" when anywhere else.

Anything else do we need to know:

This will require the creation of a global configuration that ddev checks when using the optional @project parameter. This is similar to how drush works.

[rickmanelius]

Follow-up. I don't think this is necessary until ~ 0.5 - 1.0. I think as a person uses more sites, this becomes more valuable.

[rfay]

In the normal course of work, I ended up with ddev in a bit of an unknown state, with an existing (but stopped) mysql container, and no web container, and no source directory. ddev list showed that there was a site there in the "created" state; ddev describe drupal8 did not show it, and of course it was hard to figure out what was going on.

In this case I had manually deleted containers (using docker stop/rm) related to failed tests, but had stopped one and not rm'd it. So there was a single mysql container hanging around.

So we should make sure that any containers from a site can be cleaned up using the technique advocated for this issue. It's possible we need a ddev fire-bazooka to blow everything away.

[tannerjfco]

I think providing sitename as argument to command should either be limited to commands like describe and rm, or at least scoped to commands that require a running site to execute (so start or config would not accept the argument).

Re @rfay's experience, I believe rm attempts additional cleanup even if the compose file was removed, so if that command accepted sitename as an argument, that might be sufficient to remove a site in that scenario.

[rickmanelius]

This already works for ddev stop, rm, and describe. It could probably work for start, but for now I'm going to call this done as it's been handled elsewhere.

[rickmanelius]

Good point by @rfay in that we may need to cross check this against new ddev-ui needs.

[rickmanelius]

@cyberswat Here was the original issue filed with the request to add an "@app" option prior to the specific ddev command. The discussion in this thread might be a bit out of date given that we've introduced the ability for several other commands to work outside of the app's working directory, and we should revisit.

[cyberswat]

It may be worth opening the conversation again. I ran into this today setting up for a sales call. I wanted to ddev ssh into containers from outside of the projects root folder. ddev @app ssh seemed like it would have been valuable.

[rfay]

Many of our commands take the sitename after the command. Imo all should. Putting the sitename BEFORE the command would be a major breaking change.

[rfay]

About the only thing you can't do now is ddev config and ddev start, I think this is good enough until we feel like revisiting it.