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

Thoughts on providers and toolchains? #4

Open
joneshf opened this issue Apr 9, 2021 · 2 comments
Open

Thoughts on providers and toolchains? #4

joneshf opened this issue Apr 9, 2021 · 2 comments

Comments

@joneshf
Copy link

joneshf commented Apr 9, 2021

Heya, thanks for putting this set of rules together!

I'm curious if you've thought about converting things over to providers and toolchains.

Providers allow passing information between rules. E.g. the three files that are currently archived up could instead be plain files that are shuffled along in a DhallInfo-esque provider. This would mean that there wouldn't need to be an implicit dependency on tar. It'd also mean that there would be fewer shell scripts to write (maybe none) to deal with the archiving/unarchiving.

Toolchains allow describing the interface for each tool being used to decouple the rules from the selection of which tool to use. E.g. There wouldn't be a reason to search for the proper binary on the path, it'd be done at repository resolution time. This would mean that all platforms that are supported by the dhall-haskell repo are immediately supported by rules_dhall. This could also mean that assuming the toolchain defined the interface appropriately, other Dhall implementations could be used without burdening rules_dhall unnecessarily. dhall-golang in particular would be interesting because in theory it could compile to many different platforms.

If you're interested in discussing further or would like to see a PR, lemme know.

@humphrej
Copy link
Owner

Hello @joneshf ! Both ideas sound like they would be an improvement - this would also clear up the mac/linux duplications in the download also I think.

I am not very familiar with either feature so If you want to show the way with a PR that would be cool.

Also let me introduce you to @muff1nman - he forked this repo and moved the rules forward considerably. If you are doing a PR, then you probably should base it on his fork (or we should merge his changes here).

@joneshf
Copy link
Author

joneshf commented Apr 10, 2021

Sounds good. I think while the two repos are still divergent (and this one has fewer parts) I'll make an initial PR against this one. If it seems good, I'll see about extending it to the other repo.

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

No branches or pull requests

2 participants