niv
hadolint
Our great sponsors
niv | hadolint | |
---|---|---|
16 | 24 | |
1,449 | 9,677 | |
- | 1.5% | |
6.3 | 2.3 | |
about 1 month ago | 24 days ago | |
Haskell | Haskell | |
MIT License | GNU General Public License v3.0 only |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
niv
-
NixOS + Haskell best practices circa March 2023
niv
-
Pulling themes from a git project: the nix way?
Flakes work. An alternative is niv which was once popular and provides a good developer experience.
-
What are the biggest Pain Points with NIX? And what makes it worth the pain?
Essentially you can just think of it as a standardized default.nix/shell.nix with built-in Niv integration.
-
Our Roadmap for Nix
I agree that the FP part is not the only issue. It's that the community feels a bit more academic/I'll fix this for myself in the way that works best for me.
You can indeed achieve some reproducibility with Docker. It's tricky though, as you'd have to pin exact package versions of software. If you'd `FROM ubuntu:$VERION`, and would run an `apt-get update`, you're not guaranteed to get the same software.
Nix is like ZFS, as that it breaks the wall between two previously distinct area's. Those being building software, and installing/configuration software on your OS. It's quite different from the snapshot-everything methodology that Docker uses. Yeah, one can split in multi-stage images etc, but than you'll be keeping track of which dependencies need to be moved between the stages yourself, in a manner that cannot be abstracted away, so you're doomed to repeat the same patterns over and over again.
People also state that LVM + ext3 is more than sufficient compared to the complexity of ZFS. They miss out on the fact on how much more fine grained solutions are possible with ZFS.
I've used niv [0] before flakes arrived, and am actually still using that instead of flakes. The experimental nature of them has scared me away from them, as I'm not daily involved in this ecosystem at the moment.
-
Simplest way to set up neovim
You can use something like Niv to manage additional sources. I use it to fetch some Emacs packages, for example ligature.el. Then you update the package using $ niv update.
-
Unstable vs Stable channels
One thing that made this easier was switching from using Nix channels to explicitly pinning my dependencies with Niv. I honestly never fully understood how channels worked, and it's just much nicer to have everything specified in my Git repo. The exact commit of Nixpkgs that I'm using is in my sources.json file, so "reverting" just means checking out an older commit of my configs from Git then running nixos-rebuild switch. If I were redoing my dotfiles today I'd probably use Nix Flakes rather than Niv, but I suspect that Niv is still an easier option to get started with.
-
Remove unused niv packages
Does someone know of a way to remove unused pinned packages via [niv](https://github.com/nmattia/niv)?
-
How to downgrade single package?
Pin nixpkgs, and version control it. If you're using flakes, then just version control the flake.lock alongside your configuration. If you're not using flakes, you can use niv to easily pin nipxkgs, at the expense of some boiler plate.
- Compiling emacs is killing me
-
Ditch Your Version Manager
This... This is laughable. How do I install ruby 2.6.8? Oh, there's no ruby_2_6_8, because of course there isn't. And this could be difference between a secure system and all your base are belong to us.
And they call this reproducible builds?
And that's before getting into the ridiculous
--- start quote ---
All the software that we installed depends on the specific version of the nixpkgs channel that we installed on our system [whose only version is a commit hash in a git repo]
--- end quote ---
So you need an extra tool [2] for, quote, "painless dependencies for Nix projects."
Yes, sure. I'm definitely ditching my version managers in favor of this tool, that hasn't solved these issues in 18 years of its existence.
[1] https://search.nixos.org/packages?channel=21.05&from=0&size=...
hadolint
- Dockerfile Linter
-
Writing a Minecraft server from scratch in Bash (2022)
To skip the "move your scripts to standalone files" step some devs don't like, consider something like https://github.com/hadolint/hadolint which runs Shellcheck over inline scripts within Containerfiles.
-
I reduced the size of my Docker image by 40% – Dockerizing shell scripts
This is neat :)
I love going and making containers smaller and faster to build.
I don't know if it's useful for alpine, but adding a --mount=type=cache argument to the RUN command that `apk add`s might shave a few seconds off rebuilds. Probably not worth it, in your case, unless you're invalidating the cached layer often (adding or removing deps, intentionally building without layer caching to ensure you have the latest packages).
Hadolint is another tool worth checking out if you like spending time messing with Dockerfiles: https://github.com/hadolint/hadolint
-
Top 10 common Dockerfile linting issues
With Depot, we make use of two Dockerfile linters, hadolint and a set of Dockerfile linter rules that Semgrep has written to make a bit of a smarter Dockerfile linter.
-
hadolint - Dockerfile linter
# Download hadolint wget https://github.com/hadolint/hadolint/releases/download/v2.12.0/hadolint-Linux-x86_64 # Download SHA256 checksum wget https://github.com/hadolint/hadolint/releases/download/v2.12.0/hadolint-Linux-x86_64.sha256 # Validate the checksum sha256sum -c hadolint-Linux-x86_64.sha256 # Make the file executable chmod + ./hadolint-Linux-x86_64 # Rename the file mv hadolint-Linux-x86_64 hadolint
- Haskell Dockerfile Linter
-
Is adding a USER best practice?
The most common linter I've seen and used it Hadolint, which does: https://github.com/hadolint/hadolint/wiki/DL3002 I didn't bother checking to see if alternatives also support this as well though.
-
Checkmake: Experimental Linter/Analyzer for Makefiles
Some discussion on that here:
https://github.com/koalaman/shellcheck/issues/58
The hadolint project does shell checking for Dockerfiles and it uses shellcheck:
https://github.com/hadolint/hadolint
So the approach is definitely feasible, but you do need a new project and probably it needs to be written in Haskell.
-
Dokter: the doctor for your Dockerfiles
how does this compare to something like hadolint?
Also, have you run across Hadolint for linting? https://github.com/hadolint/hadolint
What are some alternatives?
leksah - Haskell IDE
trivy - Find vulnerabilities, misconfigurations, secrets, SBOM in containers, Kubernetes, code repositories, clouds and more
update-nix-fetchgit - A program to automatically update fetchgit values in Nix expressions
dockle - Container Image Linter for Security, Helping build the Best-Practice Docker Image, Easy to start
ghcid - Very low feature GHCi based IDE
docker-bench-security - The Docker Bench for Security is a script that checks for dozens of common best-practices around deploying Docker containers in production.
elm-make
stan - 🕵️ Haskell STatic ANalyser
hpc-threshold - Small utility for validating whether HPC result is above defined thresholds
hlint - Haskell source code suggestions
nixery - Container registry which transparently builds images using the Nix package manager. Canonical repository is https://cs.tvl.fyi/depot/-/tree/tools/nixery
grype - A vulnerability scanner for container images and filesystems