Hi, I’m trying to install the latest version of duckdb (1.1.2).
The error message I’m getting is a bit cryptic:
❌ ERROR: resolution failed: constraints for group 'toplevel' are too tight
Use 'flox edit' to adjust version constraints in the [install] section,
or isolate dependencies in a new group with '<pkg>.pkg-group = "newgroup"'
Does that mean that this version brings in some dependencies which are conflicting with some of my installed packages in that environment?
Could we have a more fleshed-out error message with the exact lines to add to the [install] section? Or maybe a question asking the user to do it automatically?
Thanks.
ysndr
October 23, 2024, 6:13pm
2
Does that mean that this version brings in some dependencies which are conflicting with some of my installed packages in that environment?
Kind of yes, it says that
duckdb@1.1.2 can not be provided at all orthere is no revision of nixpkgs that has duckdb@1.1.2 and also your-other-package@x.y.z if you already have packages installed in the “toplevel” group (which are all packages that do not have an explcit “pkg-group” set)
duckdb@1.1.2 is not allowed e.g. because its broken
Could we have a more fleshed-out error message with the exact lines to add to the [install] section? Or maybe a question asking the user to do it automatically?
We are aware of these problems and have pen issues that should make the messages somewhat more relevant:
opened 06:43PM - 03 Jul 24 UTC
enhancement
team-cli
design
user-reported
**Describe the feature:**
* `flox activate` can trigger the following error (un… der certain conditions, mentioned in a linked issue.)
When an edge case error is encountered, the pre-existing feedback message is unclear.
```console
❌ ERROR: resolution failed: constraints for group 'toplevel' are too tight
Use 'flox edit' to adjust version constraints in the [install] section,
or isolate dependencies in a new group with '<pkg>.pkg-group = "newgroup"'
```
* As a user who is new to this project and Nix, I found the error message to be confusing.
The last part of the error is genuinely useful, and after taking a 2nd look I do see "pkg-group" mentioned in the docs / shows up when searching, I now realize I was just searching for the wrong keyword.
* **To be more specific I had the following points of confusion:**
1. Google search of the error message produced no relevant results, it'd be nice if either:
* The 1st line of the error was mentioned in the docs
* or the error message pointed to a relevant part of the docs where I could read for more information.
1. If I go to https://flox.dev/docs/ and search "toplevel" I get 0 results.
(I'm guessing it's the name of an implicit default group, if that's the case it'd be nice to document, the implicit default value.)
1. The error says to use `flox edit`, running that (in the same working dir that `flox activate` worked in), results in
```console
❌ ERROR: editor command failed: No such file or directory (os error 2)
```
^-- Update: This might be related to a customization I use on my system (`export EDITOR="subl --wait"`)
(Which makes it so kubectl edit yaml object & sops edit encrypted.yaml can be done using sublime text instead of vi)
The flox shell inherits this env var, (I didn't realize this at the time)
1. The error message itself didn't allow me to understand what went wrong / the nature of the error. I later understood from this https://github.com/flox/flox/issues/1733#issuecomment-2206242494
<br/><br/>
**This feature is to propose relatively small changes to the CLI's feedback message.**
I think the following proposed edit would be better:
```console
❌ ERROR: resolution failed: constraints for group 'toplevel' are too tight.
Layperson Friendly Explanation:
Some of your installed packages are configured to share dependencies. A conflict among
shared dependencies is preventing the use of a pinned version for one of your packages.
(Or you're trying to use a version of a package that doesn't exist.)
1st Potential Solution:
Try editing ./.flox/env/manifest.toml's [install] section to loosen version constraints
Example Change:
From: cdk = { pkg-path = "nodePackages.aws-cdk", version = "2.133.0" }
To: cdk = { pkg-path = "nodePackages.aws-cdk", version = "^2.133.0" }
2nd Potential Solution:
Try editing ./.flox/env/manifest.toml's [install] section to isolate dependencies
Example Change:
From: cdk = { pkg-path = "nodePackages.aws-cdk", version = "2.133.0" }
# (which has an implicit default value of pkg-group = "toplevel" )
To: cdk = { pkg-path = "nodePackages.aws-cdk", version = "^2.133.0", pkg-group = "aws-cdk" }
# Note: pkg-group is an arbitrary descriptive value, that's only significant to your config.
3rd Potential Solution:
Verify the version specified exists in NixOS packages (Latest packages are only available on a delay)
Example:
flox search aws-cdk
flox show nodePackages.aws-cdk
(This shows latest NixOS Package available is 2.146.0, yet the project's GitHub page says 2.147.3 exists)
Further Reading:
https://github.com/flox/flox/issues/1733
```
<br/><br/>
**Describe a use case of this feature:**
* This closed bug report https://github.com/flox/flox/issues/1733
explains:
* the use case
* a method of reproducing (that seems to be ARM Mac specific)
* Issue closed as it was a PEBCAK(Problem Exists Between Chair and Keyboard) type error, but there's room for UX improvement with a better error message that'd allow self-resolution of error to be more intuitive.
<br/><br/>
**AC(Acceptance Criteria):**
1. A future proof solution that's maintainable and easy to support.
* I suggest pointing to a github issue instead of pointing to docs for this reason.
* Pointing to docs as further reading is a bad idea, because it introduces docs/cli maintainability constraints, as re-organizing or renaming any docs in the future would require updating CLI error message to point to new location, or avoid doc reorg.
* pointing to a github issue has many benefits:
* decoupled from docs
* If any part of the error message is unclear, folks can ask, and the community can ask for and add further clarity. (in a way that doesn't require the CLI updates, official docs updates, or any work from maintainers, yet still serves the needs of the end users.)
* community can link to relevant docs in the github issue thread, and if docs move in the future community can point to new location.
2. Replace `'<pkg>.pkg-group = "newgroup"'` based explanation in favor of a complete and explicit/concrete example.
The original explanation in the error message is more appropriate for docs.
a complete and explicit/concrete example has an advantage in terms of SEO(search engine optimization), if an end user searches an explicit example, they're more likely to find relevant hits. If they search a generic explanation with variable placeholders, they're likely not not find further help.
Note: My proposed solution meet's all these suggested Acceptance Criteria, and solves the initial problematic points of confusion I had with the original error feedback message.
opened 01:57PM - 17 Sep 24 UTC
bug
team-cli
**Describe the bug:**
Resolving a package that is marked as `broken` in the c… atalog, will fail on acount of "too tight constraints", as the catalog-service tries to resolve with `allowBroken` as a required constraint.
Previously, the catalog service would return broken packages in a resolution leaving the validation of returned packages to the CLI.
This issue was discovered when looking for a new broken package to replace the now unbroken `tabula` package in #2088.
**Steps to reproduce:**
1. `flox init`
2. `flox install zim`
Result:
```
❌ ERROR: resolution failed: constraints for group 'toplevel' are too tight
Use 'flox edit' to adjust version constraints in the [install] section,
or isolate dependencies in a new group with '<pkg>.pkg-group = "newgroup"'
```
Expected:
```
❌ ERROR: Package 'zim' is marked as broken ...
```
**Proposed solution**
To return to the _old_ behavior, the CLI should send requests with `allowBroken = true` by default and verify the response based on the options found in the manifest. Since the verification logic is already in place, only the request generation needs to be changed.
The holistic solution would be to either
- send a request _with_ constraints, and upon failure, send another unconstrained request and verify the response.
- provide alternative pages server side and validate + pick a page on the cli -- the details on this are less clear.
Both solutions are much more invasive and might be considered after a simpler (interim?) solution has been implemented.
**Flox Version (run `flox --version` if possible):**
1.3.1
1 Like
Thanks Yannick,
For flox users having a similar issue, I was able to use the latest version of duckdb by edit my environment and adding these lines:
duckdb.pkg-path = "duckdb"
duckdb.version = "1.1.2"
duckdb.pkg-group = "duckdb"