search

haskell / docker-haskell

MIT License
63 stars 37 forks source link

Let us template the Dockerfiles #6

Closed phadej closed 4 years ago

phadej commented 4 years ago

@psftw any opinions on this?

phadej commented 4 years ago

I pushed a new variant, I still need to write the instructions how to regenerate.

I think with strectch / buster; slim / non-slim; and n-versions templating is justified.

EDIT: note, this already includes buster images, as there aren't yet upstream .debs.

psftw commented 4 years ago

Taking a quick pass at the latest iteration --

8.4.x is effectively frozen, so let's not make any changes there. Per docs,

only the two most recent minor releases will receive updates

I'm strongly against downgrading to checksums when we have GPG keys. Related: https://github.com/haskell/docker-haskell/issues/4

I'm souring on the direction these changes are taking. There is a history of being conservative and avoiding unnecessary complexity in this project. GHC is not released very often and we have only needed to maintain two Dockerfiles at any given time. Before releases I run the images through an informal battery of tests and review the results manually. This has scaled well enough to date without any major hiccups, but won't suffice as we expand to more platforms/variants. A more formal CI suite is in order. In the latest iteration of this PR (ignoring 8.4) you are expanding to eight image variants which are generated by 90 lines of code, and that code is effectively performing a few string substitutions. You also introduce your personal templating library with an initial commit of last week. I appreciate the enthusiasm, but I hope you can understand that this would introduce a significant barrier to contributors. I'm unconvinced on the necessity of more than one image per GHC-distro-arch combo. There should be a compelling reason for each variant to exist, not just the fact that it could exist. I've been pretty clear that I want to know exactly what packages are going in to the image (which can be validated with the output of dpkg -l), so hand-waving on the justification for switching to buildpack-deps is not good enough.

OK, hope this doesn't come across too harshly. I really am open to expanding the matrix and using Haskell to do the Dockerfile generation, but it will need to be done in the right spirit of the project as outlined above.

phadej commented 4 years ago

You also introduce your personal templating library with an initial commit of last week.

Which uses jinja2 inspired syntax, which is well known. I can change to mustache if it feels better.

OK, hope this doesn't come across too harshly. I really am open to expanding the matrix and using Haskell to do the Dockerfile generation, but it will need to be done in the right spirit of the project as outlined above.

Well, it did.

You asked for maintenance help, I offered some.

8.4.x is effectively frozen, so let's not make any changes there.

I didn't know that. From my perspective I would need images with newest versions of tools (cabal-install and stack and possibly others), but still providing old compilers. Perfectly even down to ghc-7.0. If that's against official policy, then these images are not for me.

Feel free to remove me from this repository.