"The goal of the Dockerfile is to specify how to transform a source code repository into something Docker can run." - @shykes

Docker users are frequently blocked when their repository contains an application which must run in multiple environments with different dependencies or is structured in a way that precludes them from using the default docker build semantics (multiple services in one repo).

Docker users currently must use custom build scripts, Makefiles, or other third party solutions in order to sidestep the current limitations of docker build which prevent their application from running in the desired manner.

Docker users currently familiar with existing unixy OSes expect this behavior to exist, tend to understand the proposed behavior inherently, and will need little to no training in order to use this feature effectively. Current potential alternatives to implementing a fix for this involve adding complexity to Dockerfile syntax and may not solve the core problem being discussed.

We can implement a solution in one step

1. Implement a new argument (suggested: -f) for the docker build command which takes a path and behaves as if the provided path was the Dockerfile.

Known Objections:

Repeatability

"A user of the software should be able to check out the repository and run docker build to get a working version of the software"

This change does not affect repeatability. Developers can continue to provide a default Dockerfile if their application has a meaningful default environment. If this is a practice we want to enforce, the existence of a Dockerfile can be required.