You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jun 18, 2019. It is now read-only.
The plumbing between hazel and cabal2bazel seems to work really well for many packages on Hackage. I'd like to be able to use the same plumbing in custom packages, such as forks hosted on github, or repos not on Hackage. Unfortunately right now I have to define my own BUILD file, and it is not obvious how to re-use some of that plumbing.
With this infrastructure, it could be possible also to write a preprocessor that runs hpack for projects that use stack and don't checkin cabal files and then kick off to hazel/cabal2bazel.
It seems like majority of the work is done here but Im still getting familiar with the code base so Im not sure how easy that would be able to make something that can be easily invoked.
The text was updated successfully, but these errors were encountered:
One benefit of not adding it directly to hazel_custom_package_hackage would be that this rule/function could be used for internal modules as well for simple haskell projects. Instead of writing the haskell_library and other rules it would generate it for you. Then the default for hazel_custom_package_hackage and github could be to include a BUILD with the calling of this rule/function.
FYI you can do this by creating an extra_packages.bzl in your repository and appending it to packages in your hazel_repositories invocation. Requires manually computing the SHA and is not really a first class API, but we're apparently doing this internally in a few places.
I wasn't aware of this two weeks ago (I'm a relatively new maintainer for Hazel), sorry for misleading.
Would still like this to be available from the custom_package family though
Yes! I discovered this too and is a nice workaround. Unfortunately we have a few custom forks in our codebase to deal with upgrading around LTS version bounds and those are the ones I'd really like to use this for.
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
The plumbing between hazel and cabal2bazel seems to work really well for many packages on Hackage. I'd like to be able to use the same plumbing in custom packages, such as forks hosted on github, or repos not on Hackage. Unfortunately right now I have to define my own BUILD file, and it is not obvious how to re-use some of that plumbing.
With this infrastructure, it could be possible also to write a preprocessor that runs
hpack
for projects that use stack and don't checkin cabal files and then kick off to hazel/cabal2bazel.It seems like majority of the work is done here but Im still getting familiar with the code base so Im not sure how easy that would be able to make something that can be easily invoked.
The text was updated successfully, but these errors were encountered: