App Container spec gains new support as a community-led effort

I think there is much more work needed than just getting the dockerfile to reproduce a docker container. As soon as it does something like "gem install foo" or npm, pip, or yum/apt, without exactly pinning the version, you have lost. Now, distributions at least try to keep compatibility in stable releases, but based on my own experience with ruby, this is not something all upstream or developers take in account.

The problem of course is that it work well enough for people to believe that, until this is deployed at scale. That's like race condition. Rather hard to track, work most of the time until suddenly, a mysterious failure happen.

> FWIW, I don't see anything about Rocket that resembles Dockerfiles, I
> hope they're not neglecting that aspect.

You could easily replace that with ansible or puppet ( or others ). The dockerfile format, while not totally horrible, still have some problems IMHO who would make it less than ideal for large scale usage.

For one, you cannot extend it ( no macros like rpm specs, for example ). While this permit to have uniform file accross deploy, it doesn't permit to encode the best practice in a easy way.

Another issue, you cannot parse it easily. Again, something like xml, yaml or json permit to create static analyzer who permit to verify and enforce best practice. Doing so for docker mean you would have to duplicate the parser, against a spec which is (afaik ) not written. Languages like python or specialized DSL like puppet have various tools, most reusing the AST of the compiler ( bandit is one example, puppet-lint is another ). And yes, I realize that it is hard to satisfy having a easy to parse language and being extensible. But here, none is done.

The syntax itself is inspired of one of the most annoying design decision of the rpm specs file, reusing the shell as the mechanism of construction of the system. Note that I said annoying, not bad, because I think you do not have the choice on this. But having specs files as shell scripts with macros make then hard to parse, prevent having nice things like "being able to fully revert a rpm" due to %post being in shell. And arguably make repeatable build harder.

Do not get me wrong, I am quite they didn't had the choice for that, given the legacy we have in term of build scripts all over the place. But like haskell do not have the choice to offer IO functions but explicitly tell this will cause issues, I wonder how much the requirement for running shell snippet could have been reduced.