Launching flatpak apps from within an activated environment

Help
1

Hi there!

Flox looks like an absolute superstar! But I can’t figure out how to make it play well with flatpaks.

I’ve set up my flox environment and activated it. Can access the programs from the command-line, alright. But then, if I launch an IDE in a flatpak from within this environment, it doesn’t inherit the (whole) env. Probably because flatpak unsets the $PATH, so we don’t get the new binaries there.

Am I missing something? Is there a way to make it work?

Example broken workflow:

flox init
flox install dioxus-cli
flox activate
dx --version # works alright
flatpak run dev.zed.Zed # the Zed IDE won't have dx installed.
codium # this "host" bin has dx accessible alright.

Any clue? (apart from ditching flatpak :sweat_smile: )

Thanks!

2

Hi @Pascalio, thanks for the feedback! You’re correct it’s likely flatpak unsetting the $PATH prior to launching a subshell, and Flox subsequently needs an opportunity to reset that as each of those subshells start. That is done by sourcing the output of flox activate from within your chosen “dotfile”, which is done to activate your “default” environment on startup. Flox will guide you through the process of setting this up on first invocation if you attempt to install a package without a defined environment (i.e. if you invoke cd $HOME && flox install hello with no active environment), but you can also do it by hand with the following:

  • create your default environment with flox init -d ~

Then, depending on your chosen shell you can add the following to the end of the given dotfile:

  • .bashrc or .zshrc => eval "$(flox activate -d ~ -m run)"
  • .config/fish/config.fish => flox activate -d ~ -m run | source

Once you’ve done this the flox activate command will run from within each of your subshells and attach to the prior activation of all active environments, including both your project and default environments.

Hope this helps!

1 Like
3

Thank you @brantley for your prompt and helpful answer! :smiley:

Indeed, the default environment strategy works well. It however obliges me to have my project-specific packages installed in this default env, if I want them to be available in the flatpak.

Alternatively, it seems to work if I add some flox activate -d ~/my_project -m run after your default sourcing in the “dotfile”. This makes “my_project” some sort of default as well… but with modularity, so to speak…

4

Indeed, the default environment strategy works well. It however obliges me to have my project-specific packages installed in this default env, if I want them to be available in the flatpak.

Hmmm … that should not be the case. The way it works is that the set of activated environments is passed down through the environment by way of the _FLOX_ACTIVE_ENVIRONMENTS variable, and then the sourcing of the output of flox activate is our “hook” by which to restore all active Flox environments to the front of your PATH. If that’s not happening then I’m overlooking something or there is a bug somewhere.

Can I just confirm which shell you’re using? If it’s zsh then can I suggest you add those same flox activate invocations to both your .zshrc and .zshenv files?

One other bit of advice would be to make sure the flox activate invocations happen last in your dotfile(s), to make sure that there is no chance for anything to run afterwards that might overwrite our efforts to configure your environment.

In summary, with your dotfile(s) modified to source your default environment the following should work:

flox init
flox install dioxus-cli
flox activate
flatpak run dev.zed.Zed

And if it doesn’t work as you would expect we would love to learn more! Just seeing the output of env from within a terminal launched from zed would be really helpful. It’s of course possible that flatpak is pruning the environment of our variables (which all tend to start with FLOX_ or _FLOX_), but I would hope they wouldn’t do that!

( And … if you do want to reconsider trying the Flox alternative, flox install zed-editor is currently at revision 0.198.3 which is about a week old at this point. :slight_smile: )

Hope this does the trick!

5

Thanks for the tips! :folded_hands:

The flox activate hook strategy is brilliant… But indeed it doesn’t work with flatpak (or zed?).

Btw, I use fish, but I also tested with old bash and got the same results.

It seems the flox env variables do get pruned. Here is why I come to this conclusion:

flox activate -d rust_dev # envs are [rust_dev default], alright.

flatpak run dev.zed.Zed 
# within zed, envs are [default]
env | grep _FLOX_ACTIVE_ENVIRONMENTS 
_FLOX_ACTIVE_ENVIRONMENTS=[{"type":"dot-flox","path":"/home/pascalio/.flox","pointer":{"name":"default","version":1}}]

Now, if I comment out the .bashrc line for auto-activating flox:

  • Well I have to activate them manually of course
  • But then, within zed, there are no flox env variable at all, meaning they’ve been pruned.
# start bash then
flox activate
flox activate -d Applications/rust_dev
# flox [rust-dev default]

# confirmed by 
env | grep _FLOX_ACTIVE_ENVIRONMENTS
# _FLOX_ACTIVE_ENVIRONMENTS=[{"type":"dot-flox","path":"/home/pascalio/Applications/rust_dev/.flox","pointer":{"name":"rust-dev","version":1}},{"type":"dot-flox","path":"/home/pascalio/.flox","pointer":{"name":"default","version":1}}]

flatpak run dev.zed.Zed

# Then within zed
env | grep _FLOX_ACTIVE_ENVIRONMENTS
# is empty (doesn't exist)
# and so are all flox variables as returned by
env | grep -i flox
# empty
# but if I then manually activate flox, then we get them of course.

So, zed doesn’t inherit the vars in flatpak. I should confirm with another flatpak to be sure it’s a flatpak thing.

Another point is:

  • if I flatpak run dev.zed.Zed with my Applications/rust_dev env activated, I get an error message from zed (or flatpak)
ERROR: ld.so: object '/nix/store/1l6if41nwjd92arvxn46jf1rkznqlq7i-ld-floxlib-1.0.0/lib/ld-floxlib.so' cannot be loaded as audit interface: cannot open shared object file; ignored. ERROR: ld.so: object '/nix/store/1l6if41nwjd92arvxn46jf1rkznqlq7i-ld-floxlib-1.0.0/lib/ld-floxlib.so' cannot be loaded as audit interface: cannot open shared object file; ignored. ERROR: ld.so: object '/nix/store/1l6if41nwjd92arvxn46jf1rkznqlq7i-ld-floxlib-1.0.0/lib/ld-floxlib.so' cannot be loaded as audit interface: cannot open shared object file; ignored. ERROR: ld.so: object '/nix/store/1l6if41nwjd92arvxn46jf1rkznqlq7i-ld-floxlib-1.0.0/lib/ld-floxlib.so' cannot be loaded as audit interface: cannot open shared object file; ignored.
  • if I flatpak run dev.zed.Zed with just my default env activated, there is no error.

→ I don’t know if it’s any relevant since, there is no flox vars inherited in zed either way. But it’s maybe worth reporting…

Then, as to flox install zed-editor, I tried it, but… zed just doesn’t start its GUI. It just sits idle in memory but does nothing. (on KDE, wayland…) I guess it’s a problem in the nix package. Other GUI apps install and run just fine with my flox.

Sorry for the lengthy message. Hope there is useful data in it!

6

I’ve just observed the same environment variable pruning on flatpak’s Yakuake. Probably a flatpak thing then.