devbox icon indicating copy to clipboard operation
devbox copied to clipboard

Lock files for Devbox plugins

Open apgrucza opened this issue 1 year ago • 0 comments

What problem are you trying to solve?

I have a Devbox plugin that installs multiple packages, but I am seeing differences in the lock files of the projects that use this plugin. Even if I specify full package version numbers in the plugin (e.g. [email protected]), the resolved nixpkgs flake references and Nix store paths within the lock files can still differ from one another. For example:

/nix/store/adi69gnl5b11y4ffzljaqlklrj1vnigd-curl-8.8.0
/nix/store/nbnlwb2crbbg9kwchflrwap6w7icf3ah-curl-8.8.0
/nix/store/qnriaiw3frdfdsicfnbybx9c4363d67x-curl-8.8.0

The problem is I'm unable to reliably pre-install packages used by the plugin in my CI environment. If the resolved nixpkgs flake reference in the Devbox project's lock file doesn't match the pre-installed one, Devbox installs the package again. This is very slow due to the number and size of packages in my plugin.

What solution would you like?

I'd like Devbox plugins to have lock files. Just as devbox.json has a devbox.lock file, plugin.json should have a plugin.lock file that behaves the same way and is checked into source control. This would mean that all users of the plugin would get the same nixpkgs flake reference for each package, allowing them to be pre-installed in a CI environment.

The Devbox CLI commands that operate on devbox.json files should be updated to also work on plugin.json files (or at a minimum, just devbox update). So, if I'm in a plugin directory, running devbox update would read plugin.json and create/update plugin.lock.

Alternatives you've considered

An alternative is to use nixpkgs flake references in plugin.json. However, this is not desirable because it makes reviewing and updating package versions harder. We do not get the benefits of pinning packages by version or (for semver packages) by a range of versions.

apgrucza avatar Jul 15 '24 14:07 apgrucza