remove the old version from the default flox environment
install the new one
That works but that looks cumbersome. So I tried just the recommended flox upgrade (in the recent release announcement) which took more time and… I actually don’t know if that changed anything since my current version is still the latest one.
One thing that is slightly puzzling to me is the notion of stable/staging/unstable and prerelease for flox versions. I would expect the next flox version to appear in unstable then progress to staging and stable, without even having to mention the name “prerelease”. But in the case of r84 it is directly available in stable.
Maybe I should just wait a bit until the dust settles down and the documentation gets updated :-).
First, regarding the install flow, you shouldn’t need to remove the older version. I believe it should just replace the version in the given environment.
Regarding upgrade, do you mind trying it again now that we’ve pushed r85? It should upgrade. If not we have a bug.
Regarding stabilities, you’re right that this is a bit confusing and we are working to make the documentation clearer. In this particular case we sent the newest release to stable right away since it included some critical fixes. Since we run the “flox” channel, we tend to be a little more cavalier with our stabilities, whereas with “nixpkgs-flox” (mapping a stability to nixpkgs) we follow the stability schedule exactly.
I can indeed see r85 and even r86 with flox search but when I do flox upgrade I get No environment changes detected .. exiting after a bunch of derivations evaluations.
flox upgrade did have had a bug that was fixed recently, and should now upgrade all packages in an environment. If you’re on an older version with the bug or just want to upgrade a single package in an environment then the command would be flox upgrade <package>, where package can either be the fully-qualified form (e.g. “stable.flox.flox”) or the abbreviated “alias” form “flox.flox”.
See the “PACKAGE ARGUMENTS” of the flox(1) man page for a description of package naming convention with flox.
UPDATE: I just noticed a few issues with the commands you mentioned above.
The above command installs a version of “stable.flox.flox” pinned at version 0.0.7-r84. With that a flox upgrade will not upgrade to a new semantic version, but it may replace the package with a new rebuild of the same semantic version if an underlying dependency is updated (e.g. libc).
Modifying flox/default environment.
While you can modify your local copy of the flox/default environment, that will just create a merge conflict when you eventually flox pull -e flox/default to incorporate our latest updates from upstream. You’re right that we’ve fallen behind on updates - I’m working to automate those updates going forward but all you should ever have to do for an environment managed by someone else is run flox pull. Thanks as ever for the feedback - I’ll log an issue to warn before allowing local modifications to an environment when you don’t have rights to modify the upstream version.
What I’d recommend
I’m pretty sure these commands will get you back on track:
flox pull -e flox/default --force # to remove your local modifications
flox install flox.flox # to install the latest stable flox to your default env
If you do that then a simple flox upgrade flox.flox will update the version of flox in your default environment, or flox upgrade will update everything in your environment (including stable.flox.flox).
I think that I got thoroughly confused with my default environment and flox/default. In my ~/.zshrc file I was activating default and flox/default. Then I got r83. After removing the flox/default activation I got r86.
Here is a bit of rambling to try to wrap my head around all this:
Maybe something that’s not yet clear to me is the workflow with environments. Actually if I think about how I should upgrade flox in my default environment, I’m thinking that I shouldn’t have to even use the flox/default environment. I should just be able to subscribe to the flox channel and install from there.
It feels weird to pull from an environment to upgrade just one package. My mental model is currently that I would pull from an environment to grab a coherent set of packages for a specific purpose (I don’t know, like “python development tools”).
Unless you see flox/default as this set of packages because tracelinks is also in there? Then my approach of enabling default and flox/default when I start a shell is the right one isn’t it? Then I don’t understand why I got r83. This gives me r86 but I’m not sure I’m supposed to do that because now I created a new generation in flox/default
â—‹ flox activate -e flox/default -- flox --version default
Version: 0.0.7-r83
~
â—‹ flox pull -e flox/default default
Already on 'x86_64-darwin.default'
Your branch is up to date with 'origin/x86_64-darwin.default'.
Everything up-to-date
~
â—‹ flox activate -e flox/default -- flox --version default
Version: 0.0.7-r83
~
â—‹ flox upgrade -e flox/default flox.flox default
created generation 6
~
â—‹ flox activate -e flox/default -- flox --version default
Version: 0.0.7-r86
If I rollback
â—‹ flox pull -e flox/default --force default
Already on 'x86_64-darwin.default'
Your branch is up to date with 'origin/x86_64-darwin.default'.
Total 0 (delta 0), reused 0 (delta 0), pack-reused 0
To /Users/etorreborre/.cache/flox/meta/flox
+ 8c76823...e3607ca x86_64-darwin.default -> x86_64-darwin.default (forced update)
~
â—‹ flox activate -e flox/default -- flox --version default
Version: 0.0.7-r83
I’m back on r83 from the flox/default environment and I still have r86 in my default environment.
One other thing to note - if you ever wanted to duplicate and make local modifications to an environment managed by someone else then these commands may be useful:
Yes, that was what I was referring to when I mentioned I had fallen behind on updating the flox/default and flox/prerelease environments. At the moment I’m bumping those manually but it is our intent for those environments to be automatically managed going forward. Apologies that is probably the biggest source of confusion here!
Precisely - at present flox and tracelinks are the only tools we are serving up in the flox/default environment, but we anticipate adding more to this list over time, and that will be the place where you can always find our latest supported versions. With that you should always be able to flox pull -e flox/default and know you are up-to-date. Future versions of flox will also warn you when new generations are available for download so that upgrades can be as simple as responding “yes” to an upgrade prompt. (That feature should be in place in a few weeks.)
This is all great feedback - thanks as ever for your time!
