State of Brittany development? #309

New Issue

2020-07-07T23:16:38+02:00

vaclavsvejcar commented

2020-07-07 23:16:38 +02:00

(Migrated from github.com)

First of all, I'm really happy with Brittany and big thanks to all of you authors and contributors. Brittany suits me much better than Ormolu, as I don't like when I cannot choose how my code will look like. However, it seems (at least to me) that Brittany development is somehow stalled. There are many nice features in planning phase or as existing PR (such as better support for GADTs, imports formatting, GHC 8.10 support, formatting of sum types), but no real progress seems to be done on them.

I fully understand that authors and contributors might not have enough time to invest it into Brittany, so I'd like to ask if there's anything we can do about it? Personally, I'd love to contribute to Brittany, but have no idea about its internals, I know I can just read the source code, but guess I still might miss some context, have you considered to write some design overview to make it easier for any potential new contributors? Another thing, what about any sort of sponsorship, would'n that help you to make more time for development?

This is really not meant as any kind of criticism, I was just worried about Brittany future, as it is the tool I use daily and love to use, and will gladly help as possible. ✌️

First of all, I'm really happy with _Brittany_ and big thanks to all of you authors and contributors. _Brittany_ suits me much better than _Ormolu_, as I don't like when I cannot choose how my code will look like. However, it seems (at least to me) that _Brittany_ development is somehow stalled. There are many nice features in planning phase or as existing PR (such as better support for GADTs, imports formatting, GHC 8.10 support, formatting of sum types), but no real progress seems to be done on them. I fully understand that authors and contributors might not have enough time to invest it into _Brittany_, so I'd like to ask if there's anything we can do about it? Personally, I'd love to contribute to _Brittany_, but have no idea about its internals, I know I can just read the source code, but guess I still might miss some context, have you considered to write some design overview to make it easier for any potential new contributors? Another thing, what about any sort of sponsorship, would'n that help you to make more time for development? This is really not meant as any kind of criticism, I was just worried about _Brittany_ future, as it is the tool I use daily and love to use, and will gladly help as possible. ✌️

vaclavsvejcar commented

2020-07-21 08:18:13 +02:00

(Migrated from github.com)

Hi, not sure if this question has been noticed, maybe can I ask you directly @lspitzner or @eborden? I'd really like to help with Brittany development anyhow, but I'd really need some hints from the beginning.

tfausak commented

2020-07-21 14:07:10 +02:00

(Migrated from github.com)

I can't speak for them, but I think it's safe to say that we'd be happy to have more Brittany developers 😄

I can't speak for them, but I think it's safe to say that we'd be happy to have more Brittany developers :smile:

eborden commented

2020-07-21 18:46:01 +02:00

(Migrated from github.com)

Totally agree with @tfausak. I believe @lspitzner had some docs put together about architecture, etc. I'm not sure where they are.

It might be worthwhile to add a beginner friendly label to issues. That at least might help build an on ramp into contributing.

Totally agree with @tfausak. I believe @lspitzner had some docs put together about architecture, etc. I'm not sure where they are. It might be worthwhile to add a beginner friendly label to issues. That at least might help build an on ramp into contributing.

eborden commented

2020-07-21 18:46:48 +02:00

(Migrated from github.com)

Aha, here are some of them.
https://github.com/lspitzner/brittany/blob/master/doc/implementation/index.md

Aha, here are some of them. https://github.com/lspitzner/brittany/blob/master/doc/implementation/index.md

❤️ 1

lspitzner commented

2020-08-10 23:08:58 +02:00

(Migrated from github.com)

Sorry for the late response.

This has gotten somewhat long, so I'll prefix with a short summary:

cabal UI breaking changes broke my maintenance workflows, I decided to switch to nix, learning and setting up nix was a pain but now finally I have nix-expressions that correspond to a local, reproducable CI setup. With some luck I'll be able to get back to doing actually feature development for brittany in the next weeks.

I know I have been mostly silent for a long period (once more), but I have indeed consistently spent time towards maintenance of brittany over the last week(end)s. The problem is that my build-tooling scripts broke with cabal-3.0 and as a consequence I decided to switch to a nix-based workflow. Both to help with that and to get reliable CI (for brittany and its deps).

Nix is a mixed bag. Idea is really nice, but very little is documented and the steps for getting a CI setup that can test against multiple GHC versions are not really explained anywhere. I am using iohk's haskell-nix infrastructure, which is under active development. If you are tinkering with nix expressions, I found it easy to end up recompiling everything (including bootstrapping ghcs). So developing nix-expressions is a really slow process. Especially if you then test the nix garbage-collection, and accidentally garbage-collect a tiny bit too much (bootstrapping ghc again, yay :D).

So, outlook:

The nix setup is almost where I want it, and I have nix-expressions that essentially do the same that the brittany CI currently does, only reproducably and locally, with proper caching (and garbage-collection thanks to nix)
I will continue using nix and push the expressions for brittany somewhat soon. Will take some more hours to clean up and do final testing.
Decided to drop support for ghc<8.4 soon, probably with the next release.
For other devs nix will be completely optional. I think it is worth the effort, but learning nix and switching is a huge investment (time-wise).
Will keep the existing CI around for now.

I am tempted to write some blog posts both about the nix setup that I ended up with now (my attempt at a "how to use haskell + nix with an emphasis on replacing CI") and a more philosophical "how would my ideal build-tooling / CI infrastructure for haskell look like".

But I realize that this would delay any actual brittany feature development even longer..

Sorry for the late response. This has gotten somewhat long, so I'll prefix with a short summary: > cabal UI breaking changes broke my maintenance workflows, I decided to switch to nix, learning and setting up nix was a pain but now finally I have nix-expressions that correspond to a local, reproducable CI setup. With some luck I'll be able to get back to doing actually feature development for brittany in the next weeks. I know I have been mostly silent for a long period (once more), but I have indeed consistently spent time towards maintenance of brittany over the last week(end)s. The problem is that my build-tooling scripts broke with cabal-3.0 and as a consequence I decided to switch to a nix-based workflow. Both to help with that and to get reliable CI (for brittany and its deps). Nix is a mixed bag. Idea is really nice, but very little is documented and the steps for getting a CI setup that can test against multiple GHC versions are not really explained anywhere. I am using iohk's haskell-nix infrastructure, which is under active development. If you are tinkering with nix expressions, I found it easy to end up recompiling _everything_ (including bootstrapping ghcs). So developing nix-expressions is a really slow process. Especially if you then test the nix garbage-collection, and accidentally garbage-collect a tiny bit too much (bootstrapping ghc again, yay :D). So, outlook: - The nix setup is almost where I want it, and I have nix-expressions that essentially do the same that the brittany CI currently does, only reproducably and locally, with proper caching (and garbage-collection thanks to nix) - I will continue using nix and push the expressions for brittany somewhat soon. Will take some more hours to clean up and do final testing. - Decided to drop support for ghc<8.4 soon, probably with the next release. - For other devs nix will be completely optional. I think it is worth the effort, but learning nix and switching is a huge investment (time-wise). - Will keep the existing CI around for now. I am tempted to write some blog posts both about the nix setup that I ended up with now (my attempt at a "how to use haskell + nix with an emphasis on replacing CI") and a more philosophical "how would my ideal build-tooling / CI infrastructure for haskell look like". But I realize that this would delay any actual brittany feature development even longer..

👍 4

lspitzner commented

2020-08-10 23:25:55 +02:00

(Migrated from github.com)

@vaclavsvejcar thanks for the positive feedback, it is good to know that brittany is useful and that you would like to help. I realize I have not even answered that question - how you can help - so far.

Thing is, unless you are a nix wizard, I am currently blocked on things that you probably cannot resolve. The biggest hold-up for the last (half-?)year has been the haskell build tooling.

So for now I will march on and try to polish my local build setup. Once done I will get back to looking at actual brittany features and then look into how others might help with those.

@vaclavsvejcar thanks for the positive feedback, it is good to know that brittany is useful and that you would like to help. I realize I have not even answered that question - how you can help - so far. Thing is, unless you are a nix wizard, I am currently blocked on things that you probably cannot resolve. The biggest hold-up for the last (half-?)year has been the haskell build tooling. So for now I will march on and try to polish my local build setup. Once done I will get back to looking at actual brittany features and then look into how others might help with those.

❤️ 3

tfausak commented

2021-11-28 15:46:15 +01:00

(Migrated from github.com)

Closing for now. See #358.

Sign in to join this conversation.

No Milestone

No project

No Assignees

1 Participants

Notifications

Due Date

The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: hexagoxel/brittany#309