I’m trying to get more of these types of programs running under Oil. (And yes, they are written in shell, which isn’t immediately obvious.)
If there’s an asdf user out there who understands how it works and wants to help, let me know!
I used a bunch of tools like this but this is probably the best one.
I’ve just shifted to it from rbenv. looks good so far.
Ohhh this is great! Now if only someone could write a good guide for shipping Nix environment specs for a project under development then we could have a “unified” way to set up dev environments for almost any projects
I’ve had trouble in Mac OS, this slowed down the terminal’s start time some. I’m pretty sure it’s not asdf’s problem specifically but it was a significant slowdown
Is there an issue on the issue tracker for this? I think we recommend using brew --prefix or something like that in the docs for finding the right path, but it’s really slow. Much better to hardcode the path. I’ve got some plans to simplify asdf and make the install process easier.
I am having a fantastic time using nix shells for my development environments. What is asdf offering that I can’t get from nix?
ASDF is much simpler and offer simpler CLI by sacrificing power and configurability. Nix is more like “system configuration manager” while ASDF is just version manager. I have recently completely moved from the ASDF to Nix in all my development projects.
Funny, I just tagged a new patch version of asdf a couple hours ago: https://github.com/asdf-vm/asdf/releases/tag/v0.7.3
The low-level package manager for Common Lisp is also called ASDF. I swear, if I ever write a package manager, I am going to call it arst, for reasons of Colemak.
Has anyone tried just executing the development environment in a Docker container? That way each application doesn’t need to get a virtual environment. I could just try it, obviously, but I’m wondering if there was some long term trouble doing that.
Overall Docker will be slower:
Docker will cache less without tricky mounting shenanigans, as the entire pip install ... | npm install | bundle install in your Dockerfile will commit a layer atomically, and future installs will proceed “from scratch” even for non-updated packages
pip install ...
Docker execution has a fixed overhead. Especially on macOS or Windows, where the actual execution environment is within a VM.
commands that need to access the host file system or persist data become tricky, requiring mounting shenanigans. Again on macOS or Windows, accessing mounted data can be slower, sometimes prohibitively so. For example, an engineer at my company tried running an Elasticsearch container for a project on a macOS machine with a mounted volume to persist the index. Even with the fastest mount setting, it was too slow to complete index creation in MAX_SINGED_INT_32 milliseconds.
permissions for mounted volumes is annoying.
Docker does a bad job reclaiming it’s storage space. At my previous job, those who did regular Docker builds would continuously allocate larger portions of their drive to Docker.app; or would destroy their caches and re-install regularly. Docker’s built-in commands for this were either too reluctant to delete data, or had extremely long run times (hours to days of a pegged core and drained IOPS). This is easier to manage on Linux hosts, but is still worth thinking about.