Dockerfile

[calebcase]

No description provided.

[Lewiscowles1986]

I think it would be a good idea to have an entrypoint that is a shell-script using this as one of many optional actions, provisioning for arbitrary container command execution.

[hasufell]

I don't see why people keep trying to stuff Dockerfiles into upstream repositories. There are a bazillion ways you would want to write them for a given application. Just let people deal with it and publish those on dockerhub themselves.

[Lewiscowles1986]

The why is quite simple. It eliminates the need to know how to build and allows people to simply use the project, which for something like Sandsifter increases the range of hardware it is used upon and documents the build process to eliminate inconsistencies and missed steps. It becomes the best build documentation there is, and when done correctly with an entrypoint script facilitates basic usage through the provisioned arguments to that script.

[hasufell]

Build instruction belong into a proper README, not into a Dockerfile that people may know or not know how to read (it's not even close to proper build documentation, especially because it already contains distro-specific steps, package names, ...). The rest are just good arguments for uploading an image to dockerhub, not adding a Dockerfile to this repo.

[calebcase]

There is a gracefullness to the build instructions in the README being as simple as make and a list of required technologies as short as docker. For interested parties, the Dockerfile distills into repeatable steps going from some common base system to working code. Having this in the upstream project helps ensure it remains an accurate representation of the build process. It can be especially effective if the upstream maintainer finds utility in it and uses it in their dev workflow (as this will generally ensure it is kept up to date).

@xoreaxeaxeax Are you interested in merging this? Should I invest the effort to build an entrypoint that covers the other tools as @Lewiscowles1986 suggests?

[Lewiscowles1986]

it's not even close to proper build documentation, especially because it already contains distro-specific steps

Most GNU + Linux does contain distro specific steps, however, most distro packages if you know the name can be found in other distros.

As an aside to what "might be" the case for this one first iteration of a Dockerfile, there is nothing forcing you to undertake distro-specific steps, or contributing distribution agnostic steps.

I'd be happy to co-operate with you or anyone else on making a multi-stage docker file so that the build steps distro-agnostic are present, working on an entrypoint, so that the final image does not become bloated with build-dependencies.

I'm unsure how much of docker you are familiar with, but the notion is that it's about as distro-agnostic as it gets. You can run Ubuntu packages on Redhat, vice versa; so there is not some problem with it running. Also, it doesn't pollute the host OS (although it does add a little overhead on-top of the runtime).

The rest are just good arguments for uploading an image to dockerhub, not adding a Dockerfile to this repo.

I have a feeling this is more of an emotional war, which honestly isn't worth the energy. I've specifically provided solid reasons for adding the option of a Dockerfile, which has nothing to do with dockerhub and are accessible to users running docker build . just as much as they are for docker run -d --rm xyz/sandsifter

[Lewiscowles1986]

@calebcase I was just making a suggestion. It doesn't have to be a part of this PR, or even the project. It was an area for improvement so I thought I'd add a comment in-case the subject took your fancy. I have no authority here and think the fact it's a git repo leaves it open to further contribution down the line.

[Beanow]

There's not really a need to namespace the code so thoroughly, as installing a dozen other applications or different versions would be an anti-pattern for running containers. /sandsifter or /app would suffice.