Open jpalomaki opened 1 year ago
I completely agree with you that having an official docker image for Nim would be a huge help in getting more people to adopt the language. With containerized deployments being so popular in the cloud these days, having a Nim image readily available would make it much easier for developers to deploy. And of course, the "green official badge" is always a nice touch that can provide peace of mind for users who are concerned about security and reliability. I think providing an official Nim docker image would be a great way to lower the barriers to entry for developers and organizations.
I would also love to see documentation that explains how to use the official Nim docker image. This would be a great resource for new developers who are just getting started with Nim and docker.
Here's a first stab at what a Dockerfile
for Debian 12 could look like: https://github.com/jpalomaki/docker-nim
Adapted from Rust's bookworm Dockerfile.
I have tested that compiling a simple hello world example within a container from this image seems to work fine (on amd64):
docker build --no-cache -t nim:2.0 2.0/bookworm
docker run --rm nim:2.0 /bin/sh -c 'echo "echo \"Hello, world\"" > hello.nim; nim c hello.nim; ./hello'
I've also tested a multi-stage build (using Google's distroless for final image) like this, which seems to work okay:
app.nimble
# Package
version = "0.1.0"
author = "jpalomaki"
description = "Nim app"
license = "MIT"
srcDir = "src"
bin = @["app"]
# Dependencies
requires "nim >= 2.0.0"
src/app.nim
echo "Hello, app!"
Dockerfile
FROM nim:2.0 AS builder
WORKDIR /usr/src
COPY . ./
RUN nimble build -y -d:release
FROM gcr.io/distroless/base-debian12:nonroot
COPY --from=builder /usr/src/app /app
CMD ["/app"]
Question: where can I find a Linux arm64 tarball distribution for nim?
There are only tarballs for 32/64-bit x86 on Linux, for other architectures you have to build it yourself.
There's also https://github.com/nim-lang/nightlies/releases/tag/latest-version-2-0 but it won't match the normal version 2.0.0 directly 1:1 because those are build from the newest commits in that branch (that will go into the next bugfix 2.0.x release)
it won't match the normal version 2.0.0 directly
If you want to build exactly a released version from nightlies, in the release article for that version (e.g. https://nim-lang.org/blog/2023/08/01/nim-v20-released.html), there is always a direct link to the nightlies version of the release.
To build "normal version 2.0.0 directly" use https://github.com/nim-lang/nightlies/releases/tag/2023-08-01-version-2-0-a488067a4130f029000be4550a0fb1b39e0e9e7c
oh, right, thanks, I didn't find the 2.0 version commit tag in the nightlies with the search for some reason
@jpalomaki you can use that one for now
@Yardanico Hmm, I'd not want to rely on a nightly build for release docker images (but can of course test with one).
Is there a reason Linux release tarballs aren't provided for other CPU architectures than x86_64?
Would it be possible to start shipping "official" release tarballs for other supported Linux architectures (e.g. arm64)?
Greetings,
I stumbled upon this issue through this comment.
I created a Docker image set of Nim 2.0.0 here.
https://github.com/theAkito/docker-nim
It's a multi-platform image with an intersection of what CPU architectures Nim & Docker support.
If it's fine for whoever is in charge of this issue, I am willing to continuously maintain such an image!
Abstract
Provide an official docker image for Nim, similar to Rust or Python
Motivation
An official image could, in part, help developers adopt Nim.
Description
Approximate steps to make this happen:
[ ] Get upstream approval for doing this, i.e. nim-lang maintainers agreeing to publish an official image
[ ] Figure out who's going to maintain the official images going forward (the docker-library maintainers require some level of commitment from upstream/community, to ensure official images are kept up-to-date, secure etc).
[ ] Set up the image GitHub repository, implement
Dockerfile
s etc, and test the new images[ ] Post a PR or two over at https://github.com/docker-library and get them reviewed and merged
[ ] Update relevant nim-lang.org documentation to guide users to use the official image
[ ] Announce the official image in appropriate channels
Alternative to this proposal, is to continue using the community-maintained image.
No major downsides of this proposal are identified at this time.
For more details, see original Nim Forum thread.
Code Examples
Hypothetical, multi-stage example with the official Nim image as build image, and distroless as final base image (build producing binary named
app
):Backwards Compatibility
Some-level of backwards-compatibility with the existing community-maintained nimlang/nim image would help users migrate to the official image