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

hpack all packages in a project with one invocation #347

Open
quasicomputational opened this issue Dec 19, 2018 · 8 comments
Open

hpack all packages in a project with one invocation #347

quasicomputational opened this issue Dec 19, 2018 · 8 comments
Labels

Comments

@quasicomputational
Copy link
Contributor

Currently, hpack is totally project-agnostic. If you're working in a project with multiple packages and you want to regenerate many or even all of the .cabal files, you have to invoke hpack for each package. For cabal-install projects, that can be quite the hardship; it's OK for stack because of the built-in hpack integration (i.e., stack build will regenerate the package descriptions for you).

I think it'd be nice to have a hpack mode that'd re-run hpack for all the packages in the project. This would need a --project-file flag to point hpack at the .project file, if it's in a non-standard place. There's also the problem that cabal.project files don't have a parser we can use. (I do have some code for this but it'd need some polishing before release.)

@sol
Copy link
Owner

sol commented Dec 19, 2018

How about find -name package.yaml -exec hpack {} \;?

@sol
Copy link
Owner

sol commented Dec 19, 2018

Not eager to add cabal specific features, but we could consider to do the find equivalent on e.g. --all.

@quasicomputational
Copy link
Contributor Author

One problem with that is that it'd not work if you're in a subdirectory. cabal-install and stack both go up the directory tree until they find a project description and then they'll do the right thing, but presumably hpack --all wouldn't.

@sol
Copy link
Owner

sol commented Dec 30, 2018

@quasicomputational if a proper solution to this requires to be aware of cabal.project then do you think having this in a separate executable/project would be an option?

@JonathanILevi
Copy link

I think that the best solution would be to be cabal.project aware. Using hpack on only and all the packages in cabal.project (or more ideally some way to specify which ones). Maybe a project.yaml? Either way I think a separate executable would be fine (hproj? 😄)

@sol
Copy link
Owner

sol commented Nov 10, 2020

@quasicomputational did you do anything here? I would want to see a proof-of-concept of this in a separate project / executable.

@sol sol added the idea label Nov 10, 2020
@quasicomputational
Copy link
Contributor Author

No, I never wound up writing anything to do this that would've been anywhere near suitable for general consumption - all entangled with other considerations.

@philderbeast
Copy link
Contributor

I use a fairly simple shake build script for generating cabal files in a project. It uses package.dhall files instead of package.yaml. I build this project and invoke with a bash script but maybe it could be done with runhaskell?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants