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

Support cabal.project import statements #2144

Open
TeofilC opened this issue Jan 16, 2024 · 4 comments
Open

Support cabal.project import statements #2144

TeofilC opened this issue Jan 16, 2024 · 4 comments
Labels
bug Something isn't working preserved Keep stale bot away

Comments

@TeofilC
Copy link
Contributor

TeofilC commented Jan 16, 2024

Describe the bug

Recent versions of cabal-install allow using import statements in cabal.project files.
Haskell.nix doesn't seem to support these and gives an error about the imported file not existing.

I imagine this is due to some overzealous cleaning.

Steps To Reproduce

Try building cabal-install using haskell.nix.
The cabal.project file imports cabal.project.lastest-ghc.
This will give an error about the imported file not existing and the cabal-plan-to-nix-pkgs derivation fails to build.

Expected behavior

This should work.

@TeofilC TeofilC added the bug Something isn't working label Jan 16, 2024
@amesgen
Copy link
Member

amesgen commented Jan 18, 2024

It works fine if you rename the imported file to have the .cabal extension. See here for what files end up when the plan is constructed:

pkgs.lib.any (i: (pkgs.lib.hasSuffix i path)) [ ".cabal" "package.yaml" ]); };

@michaelpj
Copy link
Collaborator

Right, so the problem is source filtering, which is quite important to avoid spurious rebuilds. I guess included files can have any extension? Then we cant' easily do a generic filter without checking through the project file first (and then checking through the things it imports...).

I guess a cheap solution would be to make the filter configurable, so people can include such things if they want them?

@TeofilC
Copy link
Contributor Author

TeofilC commented Jan 19, 2024

I guess a cheap solution would be to make the filter configurable, so people can include such things if they want them?

This sounds good to me. Recursively looking for imports sounds tricky.

Hopefully, with time, folks will settle on a convention (say cabal.project.* or *.cabal.project) and then we can just not filter that out

@philderbeast
Copy link
Contributor

philderbeast commented Apr 30, 2024

Recursively looking for imports sounds tricky.

Would it help to know which files cabal parsed?

-- | ProjectConfigSkeleton is a tree of conditional blocks and imports wrapping
-- a config. It can be finalized by providing the conditional resolution info
-- and then resolving and downloading the imports
type ProjectConfigSkeleton = CondTree ConfVar [ProjectConfigPath] ProjectConfig

parseProject :: _ -> IO (ParseResult ProjectConfigSkeleton)

With haskell/cabal#9933, we may opt to carry more data about paths when parsing;

parseProjectSkeleton
  :: _
  -> IORef [(FilePath, ProjectConfigPath)]
  -- ^ The imports seen so far, used to report on cycles and duplicates
  -- and to detect duplicates that are not cycles
  -> _
  -> IO (ParseResult ProjectConfigSkeleton)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working preserved Keep stale bot away
Projects
None yet
Development

No branches or pull requests

5 participants