3 ms·
I'd also lean towards keeping compose a separate binary, particularly given the community's concern over Docker's feature-creep, and the fact that it uses a se
by tlrobinson 12y ago
I'd also lean towards keeping compose a separate binary, particularly given the community's concern over Docker's feature-creep, and the fact that it uses a separate configuration file, and doesn't need to be the same binary for any particular reason.
Also, I filed an issue on the Github repo for this, but "machine" is already used by a command line tool on OS X and other BSDs.
Perhaps "docker-machine" and "docker-compose" are good compromises in both cases.
- hammerdr 12y agoMaybe docker could use subcommands a la git. So with docker-machine binary on the path, "docker machine" would just delegate to that. Similarly, if I had a docker-flynn binary, "docker flynn" would just magically work. This means that the main binary is composable from multiple parts and its easy to write plugins for other systems.
- tlrobinson 12y agoI actually just suggested the git plumbing/porcelain model in another comment, which would fit nicely with this suggestion: https://news.ycombinator.com/item?id=8701085 https://news.ycombinator.com/item?id=8701085
- pekk 12y agoWhy not just "flynn"? Should I really be typing "docker" before every command for the sake of someone's branding?
- pferde 12y agoImagine if git, svn, cvs all installed their own "checkout", "clone", "commit", etc. executables. It would become chaos if you had more than one installed. I prefer when various software suites keep their executables in their own namespace, if only for sake of future-proofing, to prevent naming conflicts. There are always symlinks and/or shell aliases if you want to override that locally.
- pekk 12y agoThat's nice, but it's irrelevant because there are not going to be many "flynn" executables.