Conversation
I am not sure what you mean ... installing
Generally speaking, though, I'd rather not add |
@@ -3,7 +3,7 @@ | |||
FROM alpine | |||
|
|||
# Enable HTTPS support in wget. | |||
RUN apk add --update openssl | |||
RUN apk add --update --no-cache openssl bash |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How about adding && apk cache clean
at the end of this command, too? We shouldn't need the cache after this point.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure I understand how apk
works, but running with --no-cache
means there's no cache to clean up. Are you proposing to do that instead of --no-cache
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, good question. I just ran apk cache clean
in a pristine Alpine image, and it said ERROR: Package cache is not enabled.
. Sp that command clearly makes no sense here.
Now I wonder whether --no-cache
makes any difference?
That's a bit contradictory statement because image increased by 3MB, which at the uncompressed size of 158MB is less than 2% difference. Using Nix we'd be increasing by 17%.
I understand not everyone needs bash, but those that do (for example using the image with a CI) this is really nice. I do see your point, if we add too much stuff we're better of at maintaining |
Oh and another thing, |
The beauty of it is that we don't have to do anything at all. Anybody who wants to base his personalized docker image on ours can do so just fine without coordinating with us in any way. Just create a derived image and add anything you want. There's no need to do that here. |
OK, would you be opposed to having another image in this repo then, which would include the common tooling? |
I would rather not have another image in this Git repo, but I think it would be fine to have another, separate Git repository that's built and published in docker's NixOS organization. I'm not sure what a good name would be ... maybe |
@garbas to answer your question why are low hanging fruits like this not done, but they are so easy? Well, there's always someone that doesn't like something because we're sparing 3MB to trade convenience, so I'm happy if you take this battle on, I'm giving up for now. |
Suggested by @domenkozar in #5. With this change, /var/cache/apk is empty at the time we try to clean it, so we must use --force to prevent the build from failing.
That is a pretty unfair description of the situation. I couldn't care less about 3MB. My concern is that we should implement this kind of thing properly. For starters, the notion of using Furthermore, I believe that many people don't care for So the reason why I kinda resist your low-hanging-fruit solution is because I think it's a bad solution. |
It's often useful to have bash available for executing scripts in the container.
I've opted not to use Nix to install bash as that would require fetching nixpkgs, which would make the container much larger.
--no-cache
spares some extra storage from the container.