A problem that I seem to have with Flox sometimes and haven’t been able to figure out is what to do when I have an environment with some package installed and I can see a newer version of a package with flox show but running flox upgrade <package> or just flox upgrade does nothing. When I install that package into a new flox environment with no other packages I do get the latest version from flox show so I assume that the problem is that it’s being held to an older version by dependencies with other packages in the original environment. I thought that putting the package into it’s own pkg-group with no other packages would help in that case, but it doesn’t seem to matter. When I have this problem how can I find out what is holding this package to an older version in this environment?
Yeah, this is a rough edge and your instinct about pkg-group isolation is fair but I’m guessing you are also publishing to multiple target systems?
The resolver has to find a version available for every declared system, so a newer version built only for some platforms gets silently skipped and flox show doesn’t reflect this because it lists what exists anywhere, not what’s resolvable for your system set.
Solo pkg-groups don’t help because systems constraints are per-package, not per-group, but you could run run flox upgrade <group> one at a time and see which is failing.
To confirm: check flox list -c for your options.systems, then temporarily narrow it to just your current platform and retry flox upgrade <package>. If it bumps, that was it. From there you can either leave systems narrowed (if multi-platform was aspirational) or set per-package systems on just the laggards so the rest of the env stays portable.
If narrowing doesn’t help, next suspects are a stray version descriptor or a renamed pkg-path upstream.
Thanks, I disabled all systems other than my current one in the options and I was then able to update the package to the latest version from flox show. I was curious about which system was the culprit so I tried adding each back one at a time and uninstalling/reinstalling the package to see which version I got. To my surprise, I kept getting the latest version even after restoring all of the systems that were originally there. I don’t understand how that’s possible but at least now I’ve got the version of the package that I need and something to keep in mind if I run into this again.
I think you lucked into a sync issue resolving itself, where the catalog page finished updating while you worked on it.
It’s good to have this trick in your pocket though, as sometimes you will need to narrow it down and investigate.
Glad it resolved either way!
Some additional troubleshooting tips when this scenario happens. You can search for the package page on FloxHub which for each package version, will show the available systems where that package version is available. If your environment supports more systems than what the package version has available, the environment packages in the same package group will not be able to update.
For example, below is the “hello” package, and for each package version you can see which systems are supported. So in this case, version 2.12.3 has 4 supported versions, so it should be able to update fine. If one of systems support is missing for a particular package version, that is likely the problem. It could be an eventually consistency issue with the metadata or build system, or it could be because there is an upstream problem for that system.
We are working to make these non-happy-path issues more understandable as we know they can be confusing when encountered.
