Querying flox for metadata about a package's transitive dependencies and a package's files

Help
1

New-ish to flox but I really love it. You guys realized that nix was too complicated for your team’s 0.1X dev AND that docker was complecting development environments and deployments. Now I have a reproducible environment and I’m not worried about busting my docker cache or watching sudo apt-get update for the millionth time. Amazing. Thank you!

Anyway, I’ve spent some quality time with the docs and I’ve used various package managers in the past, but I have the most experience in pacman and emerge. So, both provide some verb that answers the question. What are the packages/versions of those packages that package X depends on, i.e. transitive dependencies. And another one is, which files came with this installation for package X. Does flox plan on having this, or is this something one would use the underlying nix for?

When working with flakes it’s clear that sometimes the line b/w flox and nix is very thin. I get the impression there are certain things flox lacks b/c they can be answered by nix? Is this such a situation?

2

Thanks for the kind words!

So I hear two questions:

  • How do I see the transitive dependencies for a given package?
  • How do I see the files provided by a given package?

These aren’t directly exposed as part of Flox at the moment, but there’s still a way to get that information in the mean time if you’re ok with using some Nix tools.

Say you have ripgrep installed in your environment and you’ve activated it:

$ flox init
$ flox install ripgrep
$ flox activate

You can get the Nix store path of the package like this:

$ realpath $(which rg)
/nix/store/md9kfvsz7axcb5b1z2yw2mybi3lhxyha-ripgrep-14.1.1/bin/rg

Once you have that you can inspect the directory via ls, tree, etc to see the files provided by the package (notice that I’ve stripped off the /bin/rg from the store path above):

$ tre /nix/store/md9kfvsz7axcb5b1z2yw2mybi3lhxyha-ripgrep-14.1.1
/nix/store/md9kfvsz7axcb5b1z2yw2mybi3lhxyha-ripgrep-14.1.1
├── bin
│   └── rg
└── share
    ├── man
    │   └── man1
    │       └── rg.1
    ├── zsh
    │   └── site-functions
    │       └── _rg
    ├── fish
    │   └── vendor_completions.d
    │       └── rg.fish
    └── bash-completion
        └── completions
            └── rg.bash

You can also use the nix-tree tool to inspect the dependency tree as a TUI:

Screenshot 2025-07-29 at 1.40.54 PM
Screenshot 2025-07-29 at 1.40.54 PM2208×1196 136 KB

or you can use the following Nix command:

$ nix path-info --recursive --size --closure-size --human-readable /nix/store/md9kfvsz7axcb5b1z2yw2mybi3lhxyha-ripgrep-14.1.1
/nix/store/lcpbdhaw5yrw96kghpq9d5z0cfq4ljq5-libiconv-109          43.7 MiB        43.7 MiB
/nix/store/nvw88hi4c7v75xmxjkzis9gz2pk125px-pcre2-10.44            2.0 MiB         2.0 MiB
/nix/store/md9kfvsz7axcb5b1z2yw2mybi3lhxyha-ripgrep-14.1.1         5.4 MiB        51.1 MiB

I’ll create some tickets for surfacing the dependency tree and package files and we can talk about how or when to implement that with the team.

As for the last part about the line between Flox and Nix, we consider flakes kind of a “if you know exactly what you want, go ahead” part of the CLI. We don’t really choose to leave things out of Flox because they’re already handled by Nix. In the case of flakes, there are just some things that you can’t do with Flox at the moment, so we provide the ability to use flakes to fill in the gaps if you’re comfortable doing so. For instance, if you want to do embedded stuff with Rust you need a nightly compiler, but Nixpkgs doesn’t even contain nightly Rust compilers. In that case it’s not that there’s a gap in Flox so much as there’s a gap in Nixpkgs, but we still want you to be able to use Flox and get your work done, and there are flakes out there that allow you to bring in nightly Rust compilers.

1 Like
3

By the way, if you want to see all the files provided by your environment, you can inspect the path pointed to by the $FLOX_ENV environment variable. That directory contains all the files from your environment’s packages merged together.

1 Like
4

I created this tracking issue to cover what I’m calling “environment diagnostics”. I created two tickets for seeing package files and the dependency tree to put under it.

1 Like