Cabal: Dependency inference from the import list

[int-index]

Assuming I have a file like this

module Example where

import A
import B

main :: IO ()
main = ...

I would like to be able to cabal v2-repl Example.hs and cabal v2-run Example.hs without creating a project.

In order to make this possible, cabal can maintain a Map ModuleName (Set PackageName) mapping alongside the Hackage index, which would get updated with cabal v2-update. Then, assuming A comes from a-pkg and B from b-pkg, this would be equivalent in behaviour to cabal v2-repl --build-depends "a-pkg, b-pkg" Example.hs. The solver will try to use the latest versions of a-pkg and b-pkg by default, backtracking if necessary.

What if there are competing packages exporting A? Then include both and GHC will rightfully ask for -XPackageImports to disambiguate. The user then has the choice to go ahead and use -XPackageImports or write out --build-depends manually in its entirety (akin to the forall-or-nothing rule that GHC uses, Cabal could have a --build-depends-or-nothing rule and try to infer package dependencies only in absence of --build-depends).

[23Skidoo]

This feels like a bit too much magic. Also cabal update will now be able to break your scripts.

How about extending gen-bounds instead so that it'd generate a build-depends list that one could paste into a script's cabal block?

[hvr]

Fwiw, cabal init has some logic for generating build-depends from your source-files; but it doesn't work from the package index, but instead works from the installed packages in the pkg-db.

[int-index]

Also cabal update will now be able to break your scripts.

It's not for scripts. The use case is to load a gist or a code snippet from a coworker in REPL to mess around with it.

For scripts I would use explicit dependencies.

[23Skidoo]

I'm quite sure that if we implement this feature people will start using it for scripts as well.

[int-index]

What if we add an option that enables this functionality and call it e.g. --playground? This would be a strong hint that it's not for scripts.

[fgaz]

include both

BAD idea: I could create a package which exports all module names in hackage and contains malicious TH/Setup.hs code and it would be executed by everyone that used that command

[int-index]

@fgaz This is evil and I have not thought about it.

[23Skidoo]

BTW, OCaml's package manager uses OS-level sandboxing to prevent malicious setup scripts from wreaking too much havoc, maybe we should think about doing the same.

[gbaz]

What would be nice would be something more modest that just _suggested_ packages which included the module names, and a command line to run with --build-depends that pulled them in.