Having easy SSH access is great! Could the default install contain composer in addition to wp-cli?
+1 here for sure
+1. Also you can’t just install composer because there is no curl to copy/paste from composer install instructions ;D You event can’t apt install curl because it’s a docker, sure there is way but not what you expect.
This is definitely an interesting idea, though I wonder if it would be better to have a dedicated container for composer related things so that the production container remains lean.
I’d be curious what your workflow is, and how much of composer’s functionality is needed within the running environment.
So for example, in my Composer workflow, I mostly just use composer update, composer install and composer dumpautoload. Very occasionally do I use composer init, but mostly I just tweak the composer.json file from a template.
These are all dev-y things, and once I get the WP plugin into a stable state, then I produce a build artifact.
I get by with having composer installed globally. Do you use more advanced features of composer, and if so, what is your current workflow? What things are you hoping to be solved by having composer running within the VM?
You can install curl.
Once you’re in the container (right-click site » Open Site SSH), run
apt-get update && apt-get install -y curl and you should be good to go 
Hm yes you right, just tried on another instance it’s working, but I’m sure first time it didn’t. I needed some special apt-get flags to do that.
@ben I like the idea of having a separate container that includes composer, Grunt/Gulp, Webpack, PHPUnit, and any other testing/more developer-type tools.
If we could selectively add these components in the Custom environment and simply re-start the container that would be excellent. In this way as many different extras could be included with less set-up and the ability to easily re-start the container without these selections.
Thoughts?
One other perk of having compser in it’s own container (I think, I’m still learning more about docker) is that the actual packages that are downloaded with a composer installor update would be cached locally in that container.
In theory, that means that if you need to update multiple packages for different sites, you could save on bandwidth and use the cached version from within the ‘composer container’.
Again, I haven’t tried this, but it is a cool thought.
I also like your idea of having more dev-y related things in their own container, especially things relating to unit and integration testing.
Before using Local, I was using vanilla docker on an Ubuntu laptop. For me, wp-cli was just another container that hooked into the DB and file volumes. The actual command looked something like this:
$ docker run -it --rm \
--volumes-from some-wordpress \
--network container:some-wordpress \
wordpress:cli user list
Scroll to the bottom of this page to see where I got it: https://hub.docker.com/_/wordpress/
Now, of course I use Local to avoid this type of thing, but I think that it’s at least possible! 
I’ll see how busy I am and if there’s time to add more things to the queue!
I’m doing some cleanup of old feature requests and this is definitely an old one! 
Local now includes composer!
As I’m writing this reply, the version that’s shipped with Local is a little outdated, but we have a ticket to upgrade to the latest version of Composer so be on the look out for the latest version soon!
This topic was automatically closed 36 hours after the last reply. New replies are no longer allowed.