Best way to add additional dependencies not part of nix pkgs

Help
1

I’m wondering what’s the best thing to add dependencies which are not part of the nix packages? E.g. some python packages or libraries from other languages like golang, rust, java, etc. Falling back to the usual tools, building sophisticated hook scripts and so on feels like a step back.

Would it be better to write a nix flake for such dependencies? I’m completely new to the nix ecosystem, so no idea how much overhead this would generate.

2

Hey :waving_hand:

To expand on the options you’ve already identified, which can be thought of as a sliding scale:

  1. You can mix-and-match toolchains (e.g. Rust) and low-level dependencies both from Flox packages (e.g. OpenSSL) with language-specific dependency management tools (e.g. Cargo). This is a perfectly good place to start if your language ecosystem already has a mature dependency management tool (e.g. with locking), you’re familiar with it, and perhaps you have existing tooling.
  2. There are Flox packages for some language-specific dependencies (e.g. python313Packages on FloxHub) which require less intermediate tooling/scripting and will provide better guarantees of reproducible environments. We’re looking at exposing more of these for other languages such as Haskell and R in the future.
  3. You can write (or use tools to generate) Nix derivations for others dependencies, either upstreaming them to nixpkgs or using them directly in Flox environments as Flakes. However I wouldn’t necessarily recommend this if you’re not familiar already with Nix due to the steeper learning curve.

In addition to those options we are working on functionality that allows you to build and publish your own Flox packages to private catalogs in a way that doesn’t require you to learn (or teach) Nix. If you’re interested to learn more about that then you can signup here: Flox | Early

Regards,
Dan

3

Thanks for the overview, this clears things up for me. Let me ask a few conceptual follow-up questions:

  1. The mix-and-match definitely works, but I see a problem: using a language-specific dependency management tool locks the dependencies through an additional file, but this is a bit decoupled from flox. Since the logic needs to be put in the hook/profile, it gets only executed/checked at first activation. While this is probably fine for a local dev env, it breaks a bit the “flox containerize” logic since it doesn’t ship the whole env ready in the image. So one is basically back writing Dockerfile-logic to preload things into another image layer. Any plans to streamline this somehow?
  2. As far as I saw, the biggest concern writing flakes for missing dependencies is fixing all broken sub-dependencies by overlays. Which is a pain, but doable if the collection of flakes is small. Are there any other topics one should have a look for regarding additional complexity creating/maintaining flakes? I’m not looking for a full explanation, just some hints.
  3. What’s the proper way to get such flakes to be included upstream? Again, only some hints :slight_smile:

Your plans for the future sound exciting, I’m looking forward to that :wink:

Cheers!

1 Like