Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

New functions for pkgs.haskell.lib #225945

Closed
deemp opened this issue Apr 12, 2023 · 4 comments
Closed

New functions for pkgs.haskell.lib #225945

deemp opened this issue Apr 12, 2023 · 4 comments

Comments

@deemp
Copy link
Contributor

deemp commented Apr 12, 2023

Project description

I'd like to propose a couple of functions that should simplify the setup of Haskell projects.
I'm not aware if they're already available anywhere.

  • getHaskellPackagesDeps - provides a list of all packages from getCabalDeps of packages p1,p2,...pN minus packages p1, p2, ..., pN. This allows for developing local packages with other local packages as dependencies. Only non-local packages will be collected.

  • ghcForPackages - uses the previous function to construct a ghc with packages. It's a ghc with dependencies for local packages provided via an override of haskell.packages.

  • It may be useful to provide a wrapper for cabal that puts the ghc with packages on PATH of cabal. That's a way to avoid conflicts between ghc versions in a devshell like haskell-language-server provides its own GHC in a devshell #225895

@cdepillabout
Copy link
Member

cdepillabout commented Apr 12, 2023

getHaskellPackagesDeps and ghcForPackages sort of sound related to shellFor. Maybe some of the internals of shellFor could be factored out into separate functions?

It may be useful to provide a wrapper for cabal that puts the ghc with packages on PATH of cabal

People have argued in the past that cabal-install should pull in GHC, since GHC is required for using cabal-install. The reason we haven't done this is because people often use cabal-install with different versions of GHC. Or even do something like getting GHC from their system package manager, and getting cabal-install from Nixpkgs.

Having some sort of wrapper around cabal-install that locks it to a specific GHC version seems like it might satisfy this request. But I don't really know how I feel about it.

@deemp
Copy link
Contributor Author

deemp commented Apr 13, 2023

What I didn't like in shellFor was that it created a shell. I got used to devshell and didn't find an elegant way to combine a shellFor and a devshell. The workaround was to make a cabalFor (let's call it so) for cabal-install with ghcWithPackages on PATH so that I could use a single cabalFor package in a devShell instead of shellFor or cabal-install + ghcWithPackages.

@cdepillabout
Copy link
Member

What I didn't like in shellFor was that it created a shell.

That's why I suggested

Maybe some of the internals of shellFor could be factored out into separate functions?

If I remember correctly, the internals of shellFor basically do what you're requesting. Factoring them out seems like a reasonable path forward.

I got used to devshell and didn't find an elegant way to combine a shellFor and a devshell

I'm not sure what devshell is, but guessing from the name of the repo, it sounds like it might be a reasonable request to be able to pass a mkShell environment to devshell. Maybe it would make more sense to open up an issue on devshell?

@deemp
Copy link
Contributor Author

deemp commented Jun 11, 2023

Indeed, it is possible to pass all *inputs from a shellFor derivation to a mkShell via packagesFrom.

@deemp deemp closed this as completed Jun 11, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants