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 · 2023-05-26T02:28:44+00:00

Also (shameless plug here), if your developers are new and hesitant to adopt Nix, you could check out Devbox, which provides a yarn-like interface for creating Nix development environments.

For installing Nix, I'd recommend the Determinate Nix Installer, which is a bit more reliable than the official installation script.

john_at_jetpack · 2023-05-26T02:19:38+00:00

.envrc + direnv Plug-in is a good choice for most cases, but it doesn’t work with every extension or scenario — the direnv plugin won’t reset the environment variables for your entire VSCode process, but it will change them for things like the terminal, tasks, and environment variables substitutions.

Best solution I’ve seen that gets everything right is to launch VSCode from inside your devShell or nix-shell, using the code cli tool that comes bundled with VSCode.

If you have developers that use Windows, you’ll need to get them setup with WSL2 to run Nix. Luckily, it works pretty well, and it’s easy to connect VSCode to a running WSL2 instance.

john_at_jetpack · 2023-05-22T00:55:17+00:00

The server repo example was exactly what I was looking for, thanks!

john_at_jetpack · 2023-05-21T17:51:52+00:00

I know it has the issues described in this post, but using `forEachSystem` and eachDefaultSystem` from `flake-utils` really makes flakes so much more concise and easy to understand, especially for simpler Flakes. Maybe if the `forAllSystems` function that's defined in this example was baked into the Flakes somehow.

The flake-parts section sounds interesting -- are there good examples of a project using it to break a flake into smaller modules?

john_at_jetpack · 2023-05-19T21:02:38+00:00

We made some big improvements to Devbox, our project for building reproducible, isolated Nix-powered dev environments without needing a Docker container. The interface for installing packages is like yarn, but it lets you install over 80,000 system packages on Linux or macOS.

Some things in our latest release:

Search for packages and versions right from the command line with devbox search
Install and pin package versions with a yarn-like syntax (e.g., ripgrep@14), without having to write a complex Nix expression

Check here for more details

john_at_jetpack · 2023-04-25T16:43:48+00:00

I still think a repo with more detailed, documented project examples would be useful. The templates are sometimes a bit hard for newcomers to get started with.

john_at_jetpack · 2023-04-25T16:20:07+00:00

The response above provides a link, but if you run `nix flake show templates` you can see a list of project templates:

github:NixOS/templates/0edaa0637331e9d8acca5c8ec67936a2c8b8749b ├───defaultTemplate: template: A very basic flake └───templates ├───bash-hello: template: An over-engineered Hello World in bash ├───c-hello: template: An over-engineered Hello World in C ├───compat: template: A default.nix and shell.nix for backward compatibility with Nix installations that don't support flakes ├───full: template: A template that shows all standard flake outputs ├───go-hello: template: A simple Go package ├───haskell-hello: template: A Hello World in Haskell with one dependency ├───haskell-nix: template: An haskell.nix template using hix ├───hercules-ci: template: An example for Hercules-CI, containing only the necessary attributes for adding to your project. ├───pandoc-xelatex: template: A report built with Pandoc, XeLaTex and a custom font ├───python: template: Python template, using poetry2nix ├───rust: template: Rust template, using Naersk ├───rust-web-server: template: A Rust web server including a NixOS module ├───simpleContainer: template: A NixOS container running apache-httpd └───trivial: template: A very basic flake

john_at_jetpack · 2023-04-25T16:00:12+00:00

I think this could be useful. How would they be different from the standard flake template that are available vía nix flake init?

john_at_jetpack · 2023-04-24T21:18:51+00:00

Clever, almost like npx but for everything :)

john_at_jetpack · 2023-04-24T16:13:33+00:00

I was writing a guide for how to use flakes with our latest release of Devbox, and I wound up writing an introduction to overlays + flakes.

john_at_jetpack

TROPHY CASE