Add Dockerfile

[rpdelaney]

This gives me an image about 18Mb.

$ docker run vivid:latest --help
LS_COLORS manager with multiple themes

Usage: vivid [OPTIONS] <COMMAND>

Commands:
  generate  Generate a LS_COLORS expression
  preview   Preview a given theme
  themes    Prints list of available themes
  help      Print this message or the help of the given subcommand(s)

Options:
  -m, --color-mode <mode>  Type of ANSI colors to be used [default: 24-bit] [possible values: 8-bit,
                           24-bit]
  -d, --database <path>    Path to filetypes database (filetypes.yml)
  -h, --help               Print help
  -V, --version            Print version

[sharkdp]

is there a reason not to use latest here, so we don't have to bump the version in the future?

[rpdelaney]

Fair question. Using :latest is seen as an anti-pattern for a few reasons. Here are some of them:

1. You're dependent on the build process of the base image distributor keeping that latest tag up to date. You don't really know what version you're getting now or later, or even that it's the latest version actually.
2. Your builds aren't deterministic. The image you build might be different from what I get when I build the next day.
3. If the docker build starts to fail, but you didn't change your Dockerfile, it's hard to troubleshoot that. How do you find out what the base image version was previously, when the build worked? What is it now, when it's failing?
4. You aren't in control of what you ship to your users. You blindly ship whatever updates happened up stream, whether you need them or not, whether they make sense for you or not.

I definitely sympathize with resistance to adding manual toil updating versions. In my experience, that can be addressed with dependency management (like dependabot, or Renovatebot) in conjunction with build tests in CI/CD. If you are anxious about those ongoing maintenance costs, I could possibly help put together a quick-and-dirty docker build workflow in GitHub Actions for you.

[sharkdp]

Thanks, that definitely makes sense. I was just thinking that maybe, those Rust images are relatively well maintained and in principle, updates to the Rust version shouldn't break backwards compatibility, i.e. vivid should continue building. But I'm okay with leaving the hardcoded version in. Having a CI check that the image still builds would be great. I don't think there is a need for an automated update mechanism at the moment.

[rpdelaney]

I added a basic docker build workflow here: 4d1cfb7

For security reasons, github won't run it here until you merge it. But you can see it running on my fork: https://github.com/rpdelaney/vivid/actions

[sharkdp]

So... I think this will always use the builtin/embedded filetypes database and themes. So there is no way for the user to customize this using ~/.config/vivid/filetypes.yml or /usr/share/vivid/filetypes.yml, for example.

[rpdelaney]

The goal would be for the vivid process to have access to these files at runtime, I think. That is, we wouldn't want to have the user rebuild the container locally every time they update their local configuration, right?

[sharkdp]

Correct. So, the user would have to --mount their host ~/.config/vivid folder (and others)?

[rpdelaney]

For context, my use case is that I co-maintain LS_COLORS. The vast number of extensions we support is getting unwieldy, so I'm interested in migrating our build to leverage vivid. Having vivid in docker would help a lot since that obviates managing a hermetic rust build process inside GHA. For a use case like that, I think it's perfectly fine to leave configuration and filesystem access to the user. Anybody who is used to working with docker is already used to dealing with that, and frankly, I for one prefer it that way.

Using docker to run applications on a consumer desktop system is not something I generally recommend, since the daemon runs as the root user and therefore it is unsafe in multi-user environments.

[sharkdp]

For context, my use case is that I co-maintain LS_COLORS.

Oh, cool! That project was a huge inspiration for vivid. Glad to see that it is still actively maintained.

The vast number of extensions we support is getting unwieldy, so I'm interested in migrating our build to leverage vivid.

That would be fantastic. We would certainly see some synergy effects in both projects.

Having vivid in docker would help a lot since that obviates managing a hermetic rust build process inside GHA. For a use case like that, I think it's perfectly fine to leave configuration and filesystem access to the user.

I understand.

Using docker to run applications on a consumer desktop system is not something I generally recommend, since the daemon runs as the root user and therefore it is unsafe in multi-user environments.

Ok, then let's leave the setup minimal and add the Dockerfile just for purposes like yours.

[sharkdp]

Thank you. I have a few minor questions.

[sharkdp]

Works great, thank you: https://github.com/sharkdp/vivid/actions/runs/5271134914