v2-build --only-dependencies solver should never fail, if v2-build --dry doesn't.

[phadej]

servant release-0.16 % cabal new-build --dry all | tail
 - cookbook-generic-0.1 (exe:cookbook-using-custom-monad) (cannot read state cache)
 - cookbook-db-sqlite-simple-0.1 (exe:cookbook-db-sqlite-simple) (cannot read state cache)
 - cookbook-db-postgres-pool-0.1 (exe:cookbook-db-postgres-pool) (cannot read state cache)
 - cookbook-curl-mock-0.1 (exe:cookbock-curl-mock) (cannot read state cache)
 - cookbook-basic-streaming-2.1 (exe:cookbook-basic-streaming) (cannot read state cache)
 - cookbook-basic-auth-0.1 (exe:cookbook-basic-auth) (cannot read state cache)
 - tutorial-0.10 (test:spec) (cannot read state cache)
 - cookbook-testing-0.0.1 (exe:cookbook-testing) (cannot read state cache)
 - cookbook-pagination-2.1 (exe:cookbook-pagination) (cannot read state cache)
 - cookbook-file-upload-0.1 (exe:cookbook-file-upload) (cannot read state cache)

servant release-0.16 % cabal new-build --dep all       
cabal: Cannot select only the dependencies (as requested by the
'--only-dependencies' flag), the packages servant-0.16.1,
servant-foreign-0.15, servant-docs-0.11.3, servant-server-0.16.1 and
servant-client-0.16 are required by a dependency of one of the other targets.

Solver should pick as much as it can, there are dependencies to be built, even there are so called in-place packages (here: tutorial depends on servant-js which depends on servant-js)

---

More concretely, given there are four categories of packages in a plan

• builtin Lives in global (non-nix-style) package db
• global Lives in Nix-store cache
• local Local package
• inplace Local in-place package

I'd need a flag to build all packages which will end in the nix-store (which IMO we should rename to v2-build store: #6105, because nix-store is /nix/store). I think that --only-dependencies is close to that. To make more people happy, the v2-build --only-dependencies could also download inplace packages.

Given that, if you go on a flight, v2-build --only-dependencies will prepare you for an offline hacking session.

[23Skidoo]

+1. The basic issue here is that if you say install --only-dependencies foo bar and bar is a dependency of foo, it will currently fail. There may be an existing ticket for the v1 case.

[fgaz]

I just ran into this problem with a backpack project. +1 on making it build store (remote) packages

Given that, if you go on a flight, v2-build --only-dependencies will prepare you for an offline hacking session

this should be fixed by the new --only-download

[NicolasT]

Confirming, ran into the same issue with a Backpack project:

Resolving dependencies...
cabal-3.6.2.0: Cannot select only the dependencies (as requested by the '--only-dependencies' flag), the packages xinu-0.1.0.0 and xinu-ffi-0.1.0.0 are required by a dependency of one of the other targets.

This is quite unexpected since neither of those packages can be a dependency of anything else (one is, however, a dependency of the other, and on has internal libraries, but I don't expect that to be an influence with --only-dependencies).

Would it help to have a (trivial) reproducer repo?

[Mikolaj]

Reproducers are always welcome. But could you try with cabal 3.8.1 first? Just in case.

[nikita-volkov]

On 3.10 this blocks me in presence of git dependencies.