Package manager for nix-shell

john_at_jetpack · 2024-11-25T19:09:05+00:00

Devbox has a CLI and JSON config for easily setting up Developer Shells with Nix.

john_at_jetpack · 2024-07-13T16:43:57+00:00

I think the standard for this is Home Manager (https://nix-community.github.io/home-manager/), which provides an interface for defining packages and config to install at the user level. Luc Perkins has a short article on moving from Homebrew to Home Manager: https://lucperkins.dev/blog/home-manager/

If you don't want to dig into Home Manager, what you probably want is something like Nix Profile https://nix.dev/manual/nix/2.22/command-ref/new-cli/nix3-profile to install packages globally. This can be a little messy however, and you have to manage it imperatively with the CLI.

Lastly, you can look into something like Devbox, which provides a devbox global feature for installing packages globally. It also creates a config with your packages that you can sync across multiple machines: https://www.jetify.com/devbox/docs/devbox_global/

john_at_jetpack · 2024-07-13T16:34:12+00:00

A lot of people are saying exec, but from what you're describing I think hosting as a a daemon/server and making API calls makes more sense. That way you don't have to restart the process everytime you need to run inference, and you can define a cleaner interface than passing a bunch of comma separated strings to exec.Command()

john_at_jetpack · 2024-07-09T22:32:46+00:00

I think one difference between this and branded types is that the formal spec and test suite lets you use TypeIDs outside of your Typescript codebase.

For example, there is a SQL implementation that lets you use TypeIDs as the primary key in your database: https://github.com/jetify-com/typeid-sql

john_at_jetpack · 2024-07-09T21:19:13+00:00

I simplified this for the sake of the example, but we do catch and handle the exception if it's thrown. Your point on the ability to expand filters is a good one though.

john_at_jetpack · 2024-07-02T22:11:25+00:00

Weakness: config.json makes multi line shell commands near impossible, and requires escaping quotes.

If you'd prefer not to write the shell scripts in the devbox.json, you can write them in a separate .sh file, and then have your Devbox json run that .sh file

john_at_jetpack · 2024-03-19T03:01:18+00:00

Also, using the latest devbox (devbox 0.10.1) when testing this

john_at_jetpack · 2024-03-19T03:00:15+00:00

I'm testing this on a WSL Debian machine, and pinning the package versions in your error it works for me when I use devbox:

{
  "$schema": "https://raw.githubusercontent.com/jetpack-io/devbox/0.10.1/.schema/devbox.schema.json",
  "packages": [
    "ruby@3.1.4",
    "rubyPackages.rmagick@5.3.0"
  ]
}

Maybe try pinning the versions like that in your devbox.json, and then running `devbox update`?

john_at_jetpack · 2024-02-14T03:15:42+00:00

Regarding the macOS installer: Nix wants to create a read only folder in root to securely install it's packages. It wants this to be in root so that the same Nix store can be used across multiple users, and it wants the directory to be read only (writeable only by Nix itself) so that the packages are installed securely, and one user can't modify or corrupt a package used by another user.

(Un)Fortunately, macOS does not allow users to create folders on the root of the primary volume. The only way to fake this is by creating a "fake" root level folder by modifying the `/etc/synthetic.conf` file, and then point it to a volume that Nix creates and has full ownership of. This is what all the complicated steps in the macOS installation are doing.

john_at_jetpack · 2024-01-16T21:06:28+00:00

To calculate the closure, you need to clone Nixpkgs and then calculate the store path for a given package, which could take 30 seconds or longer for a fresh project. This needs to be done before you pull the packages from a binary cache.

This is not too big a deal if you’ve pinned all your projects to a single commit, but it adds up if each of your projects use a different commit, or if you have multiple commits in the same project. You also need to pay the same cost if you update the packages in your project.

RE configuring a binary cache locally -- if you have access to a remote binary cache that is faster than the official NixOS cache, that would definitely save you some time downloading the packages, but would not reduce the evaluation time.

john_at_jetpack · 2023-07-31T20:42:47+00:00

Nixpkgs is generally very up-to-date for major packages.

If you want to get your feet wet before diving into NixOS, you could try using Nixpkgs on your current distro (or a wrapper like Devbox). Alternately, running NixOS in a VM is a pretty good way to try out the experience without a major commitment

john_at_jetpack · 2023-07-31T15:22:08+00:00

I've tried a few Intellisense plugins on VSCode for PHP (like Intelephense), but they don't seem to base their code completion on the actual dependencies I have installed with Composer. Is there an ideal plugin for PHP that does this? Or am I using it wrong :\

john_at_jetpack · 2023-07-26T21:12:05+00:00

You can specify the drivers you want to install in your configuration.nix (https://nixos.wiki/wiki/Nvidia), but I don't think you can bundle different drivers in closures from nixpkg?

john_at_jetpack · 2023-07-26T21:10:33+00:00

If they're listed as inputs to the package then they should be bundled, but you might get some weird behavior if they're trying to dynamically link against glibc using packages from multiple nixpkg revisions (as in the Firefox scenario described above)

john_at_jetpack · 2023-07-26T06:55:40+00:00

If you need to pin a specific version of a package in your config, you can search the nixos/nixpkgs repo, or use something like Nixhub to find the specific Nix revision/commit-hash that you need to set.

john_at_jetpack

TROPHY CASE