Turns out that it’s a version manager (now there’s another overloading: ‘VM’ to mean ‘version manager’ vice ‘virtual machine’): https://github.com/asdf-vm/asdf
* virtual machine
* virtual memory
* version manager
Amusingly:
* virtual machine is itself overloaded (do you mean OS vm or language runtime vm)
* virtual memory is itself overloaded (do you mean mapping one address space to another via MMU for process isolation or using a swapfile to have more "memory" than ram)
I propose we start calling vcs/scm programs "version managers" so we can make this overloading fully recursive! (that is it would make this the 3rd bullet: do you mean switching between version of programming enviornment or keeping track of source code history?)
there's further different types of virtual "machines". they used to be called "type 1" and "type 2",
* type 1: runs on bare metal with no OS below it (Xen, HyperV, ESXi, ... vsphere?, others)
* type 2: runs on top of an OS (qemu, virtualbox, vmware workstation, others)
kvm is I guess kind of a mix? You need to use the userspace tools to manage it so it's like qemu (type 2) but the kernel exposes lots of things directly to the guest OS/image (type 1-ish).
I was initially so confused when I started at a security software company, because of this.
Not really, all modern OS's are C virtual machines.
https://www.youtube.com/watch?v=u23loMy3wrE&list=PLYx7XA2nY5...
Do you have any thoughts on whether or not we might be missing out? Any docs we should be looking at?
Things get a bit tricker when flakes are paired with home-manager and especially nix-darwin, as the error handling leaves a lot to be desired (opaque errors that are extremely difficult to debug, leaving you with few choices outside of nuking all nix and re-starting).
For project environments, flakes don't bring much new functionality to the table. They are a nice new convention that is probably worth learning, and they do bring faster evaluation. But don't sweat it.
let
pkgs = import (builtins.fetchTarball {
url =
"https://github.com/NixOS/nixpkgs/archive/c92ca95afb5043bc6faa0d526460584eccff2277.tar.gz";
}) { };
in pkgs.mkShell {
nativeBuildInputs = [
pkgs.ruby_2_6
pkgs.shared-mime-info
pkgs.mysql
pkgs.libmysqlclient
pkgs.imagemagick6.dev
pkgs.pkg-config
pkgs.cmake
];
PKG_CONFIG_PATH = "${pkgs.imagemagick6.dev}/lib/pkgconfig";
FREEDESKTOP_MIME_TYPES_PATH =
"${pkgs.shared_mime_info}/share/mime/packages/freedesktop.org.xml";
}Definitely not as many definitions as asdf, but what it does, it does well.
Hermit (v0.39.2):
$ hermit info tflint
Name: tflint
Version: 0.39.2
Description: A Pluggable Terraform Linter
Homepage:
State: remote
Source: https://github.com/terraform-linters/tflint/releases/download/v0.39.2/tflint_darwin_amd64.zip
Root: /Users/[REDACTED]/Library/Caches/hermit/pkg/tflint-0.39.2
$ brew info tflint
tflint: stable 0.39.3 (bottled), HEAD
Linter for Terraform files
https://github.com/terraform-linters/tflint
/usr/local/Cellar/tflint/0.39.3 (6 files, 23.0MB) *
Poured from bottle on 2022-08-12 at 08:54:53
From: https://github.com/Homebrew/homebrew-core/blob/HEAD/Formula/tflint.rb
License: MPL-2.0
==> Dependencies
Build: go
==> Options
--HEAD
Install HEAD version
==> Analytics
install: 10,687 (30 days), 25,133 (90 days), 70,271 (365 days)
install-on-request: 10,683 (30 days), 25,122 (90 days), 70,251 (365 days)
build-error: 0 (30 days)
$ asdf latest tflint
0.39.3Also tfswitch has the ability to parse the required_version constraint in the terraform file and switch to the appropriate version based on that which I find quite handy.
It became a running joke that any project attempting to start with yarn (we had lots of JS devs, so of course they all try the new shiny) was only going to make a it a couple weeks before they hit some baffling, misleading, hard-to-diagnose error that was entirely solved by running "npm install". Tons of npm features missing in yarn, tons of sanity checks that npm did that yarn simply omitted. Maybe it's gotten better but it's made me even more skeptical of "common wisdom" around these things.
(To be fair, it may be better now, but this was well in to the time when folks were starting to sneer at people still using npm and running around saying how much better yarn was and how there was no reason not to use it—I can only assume these folks weren't doing much with it, because it was really easy to hit those kinds of problems.)
Are there GitHub issues for the bugs you mention?
Maybe if I got some time to explore the tool I would have a better appreciation for it, but from my experience it is too easy to mess things up.
I remember the bad old days when all that version management was typically done just right on your machine, often with different versions of python/ruby/etc installed globally with sudo.
Docker can be a pain and can be slow and it's arguably a worse-is-better solution, but it's so much less painful for consistently managing versions.
- asdf uses way more commands than it needs to. Instead of glob pattern matching for files, it reads the output of `ls` (and _many_ very similar mistakes)
- When running functions, the output tends to be collected using $(). Since this is done so much, this realllyyyy slows down execution since subshell invocations are slowwww in bash. Better is to set the global variable `REPLY` and use that directly from the callee
- The command line interface is kind of verbise and clunky and a little unintuitive
- There are too many separate plugins to use and download. Too much code duplication between plugins
I hope this doesn't sound like a laundry list of gripes, but just things to improve upon for the maintainers - I understand how hard it is to write Bash that works everywhere. Personally, I've opted to build my own (partial) solution that implements these suggestions at https://github.com/hyperupcall/woof, but my hope is that asdf will become substantially better over the years
Rest are valid, I guess. But wouldn't your efforts be better spent helping improve asdf, instead of creating a whole new system?
I thought about contributing to asdf, but unfortunately many of my pain points are deeply integrated within the design and architecture of the code itself. For example, since there is a lot of code duplication within plugins, it would be good to create a "plugin API" (I think that has recently been proposed). But that would be very time consuming to implement not just because of the already-existing code, but also because essentially every plugin is its own separate repository, usually maintained by different people. So I'd think it's not too hard to imagine how difficult making broad improvements or changes will be.
There's also the fact that writing (decently) fast and cross-platform Bash codes necessitates an essentially orthogonal coding style, which would be at odds with asdf's coding style. Even though the `REPLY` and `$()` is probably 80% of it, I would also like to take advantage of my `bash-core` and `bash-term` Bash libraries, which really wouldn't be possible in asdf (implementation-wise, that would necessitate the use of my Bash package manager)
As languages that I'm using are starting to adopt their own version manager (rust/go), I'm left using asdf pretty much exclusively for node and my eyes wander to some of the node-only tools like volta and fnm which use rust and I wondered if people were watching performance. Glad somebody is.
Asdf really simplified my daily usage.
Nearly every lang on my machine is managed by asdf. It's been a while since I last tried but I seem to recall golang and JVM stuff seemed to play better with the default installers.
Anyway, between asdf, homebrew, and my dotfiles setup, I can have a brand new machine up and running with all my favorite stuff in about 20 minutes.
I know I'm focusing on the wrong thing, but this is cool