pass options to enable container without having to go through cli prompt

[godbout]

just some thoughts. i'm coming from laradock and i was looking for something lighter. takeout seems to be a great option, but from my tests and what i can get from the code, we have to go through the prompts. that makes it hard to automatize.

to give you an idea of my workflow, i run one command through itermocil, and it opens a bunch of terminal panels, goes into the right directories, boot up docker containers with the right options, run npm run watch in them, etc... basically i call one command, i wait for 20 seconds, and my project is up with the right version of PHP, mysql, redis, etc, etc. that would be pretty nice to be able to do this with takeout. any thought?

[mattstauffer]

I love that idea! :) Do you think you could propose a syntax?

[mattstauffer]

(Sorry for the delay in response. It's been... quite a year.)

[mabadir]

I can help with a PR if there is any specific syntax in mind.

[godbout]

no worries.

the syntax, good question. kinda subjective i think. personally i'm a big fan of two things: intuitive, but also following a used consensus. i guess it'd be nice to have both. like the typical -p for port, etc..., and something more intuitive too (in the case of port, well, like --port, which in this case is also the consensus 😅️). i'll do more research and come back to you. (currently i'm automatically printing the port i need in a terminal panel and starting takeout in another one. i still have to choose manually but i have all the info i need so it's still pretty straightforward.)

[wunc]

Maybe a possible solution to this would be something like takeout taste-test, which is almost the same as takeout enable in that it runs you through the prompts, but then instead of actually executing the docker run command it just echos it out to the terminal. Someone could then just copy-paste that into their automation scripts and modify as needed.

[mattstauffer]

@wunc We could certainly enable that using something like --dry-run to any of the commands. That doesn't perfectly solve this issue, but it would help.

[godbout]

i'll try to come up with something when i have a bit more time. currently not the priority (for me). thanks!

[josecanhelp]

I love this suggestion. But it feels very similar to what docker-compose does. Once we start getting into configuration files to orchestrate containers, it might be too complex for most takeout users.

[godbout]

fair enough.

the idea though was not to mess with configuration files, but to give the ability to pass more arguments.

currently the way i handle my workflow is echoing the ports i'm using for the current project, and starting the containers manually:

the level of friction is still acceptable so i hadn't dig yet. guess closing this issue removes this from my todo list 😂️