Allow commands to infer their service context

[samuelhwilliams]

What kind of change does this PR introduce (Bug fix, feature, docs update, ...)?

Feature

What is the current behavior?

All of the devenv helper commands require explicitly saying what docker service they target.

What is the new behavior (if this is a feature change)?

All of the devenv helper commands that are implemented as function (rather than basic aliases) can 'guess' what service the user wants to run them in. It does this based on the user's current working directory and a knowledge of what docker compose services exist in the existing common-dev-env.

Possibly could turn some of the more basic aliases into functions so that they can benefit from the same behaviour (eg ex, logs, livelogs) - but some of those would be breaking changes so I've left them off for now.

I use bash so it has been tested more thoroughly there (I've been using it for the last day or so). I've given it a quick test in zsh and added some compatability routes, but I don't use zsh regularly so it's possible some edge case hasn't been accounted for. I haven't tested any other shells.

Does this PR introduce a breaking change? If so, what actions will users need to take in order to regain compatibility?

Possibly?

Checklists

All submissions

• [x] Have you followed the guidelines in our Contributing document?
• [x] Is this PR targeting the develop branch, and the branch rebased with commits squashed if needed?
• [x] Have you checked to ensure there aren't other open Pull Requests for the same update/change?

New feature and bug fix submissions

• [x] Has your submission been tested locally?
• [ ] Has documentation such as the README been updated if necessary?
• [ ] Have you linted your new code (using rubocop and markdownlint), and are not introducing any new offenses?

[sichapman]

Four related facts that might change the code: I believe the aliases that use docker require the container name And the aliases that use docker compose require the service name (top level yaml key) And the presence of container_name changes one but not the other And the lack of container_name means the container defaults to a generated name

[samuelhwilliams]

Good catch. Interesting that this is not really well highlighted by the existing code, and some functions use docker+container name on windows and compose+service name on linux/wsl (eg lint) 🤔

Also the helper alias only ever mentions name of container, so possibly a distinction that hasn't been clarified much to end users either. Presumably in most, or at least the majority of, cases the container name does match the service name.

Windows support also seems ... incomplete? Some functions have guards for windows to run winpty docker instead of ex (eg format), but others don't (eg manage. Do we still need that distinction? It feels like either a bug or missing implementation. Unsure which off the bat.

[sichapman]

I think winpty may only be needed if there will be interactive input from the user

[samuelhwilliams]

hmmm interesting, ok, good to know 👍

I've got this on the backburner slightly for now while I think about how to reconcile aliases vs function and deal with some of trickier cases when trying to infer container/service names. I still think a change in this area is more useful than not, but it's defo not the quick win I hoped for 🙏

[sichapman]

Closing due to inactivity