Do something about Cabal?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
37 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Do something about Cabal?

Ignat Insarov
# Do something about Cabal?

Hello.

Cabal is the second most used tool in Haskell after GHC. It has many
problems. It may be noticed that there is one and a half developers working on
it. This is clearly not enough to address these problems. I propose that this is
a good place to invest in.

### Problems I have in mind:

* Poor communication, lack of open source development process.

  The whole Cabal–Stack schism appears to be an outcome of poor
  communication. One of the leading developers of Cabal is even banned from
  participation somewhere in Stack circles.[1] Personally, I reported several
  issues to Cabal and every single time it resulted in sadness. Observe a
  vicious circle: core developers are overworked ⇒ they are being unfriendly ⇒
  there are fewer contributors ⇒ core developers are overworked.

  I have no hard evidence but it appears that presently, more people that strive
  to improve the Haskell build experience are outside the Cabal cabal than are
  inside.

* User experience is an afterthought.

  Cabal's user experience is horrifying. A collection of complaints is being
  compiled elsewhere.[2] There are also bugs being opened to Cabal because of
  this, requiring triage and therefore wasting the precious time of the few
  overworked developers. Stack is much more friendly — this shows by example
  that the user experience problem is not inherent and may be solved.

  It is ordinary to receive output like this:

  ```
  % cabal run example-executable
  Warning: The package list for 'hackage.haskell.org' is 84 days old.
  Run 'cabal update' to get the latest list of available packages.
  Resolving dependencies...
  cabal: Could not resolve dependencies:
  [__0] trying: example-0.1.0.6 (user goal)
  [__1] next goal: opaleye (dependency of example)
  [__1] rejecting: opaleye-0.7.1.0, opaleye-0.7.0.0 (constraint from project
  config TODO requires ==0.6.7006.1)
  [__1] rejecting: opaleye-0.6.7006.1 (conflict: example => opaleye^>=0.7)
  [__1] skipping: opaleye-0.6.7006.0, opaleye-0.6.7005.0, opaleye-0.6.7004.2,
  opaleye-0.6.7004.1, opaleye-0.6.7004.0, opaleye-0.6.7003.1,
  opaleye-0.6.7003.0, opaleye-0.6.1.0, opaleye-0.6.0.0, opaleye-0.5.4.0,
  opaleye-0.5.3.1, opaleye-0.5.3.0, opaleye-0.5.2.2, opaleye-0.5.2.0,
  opaleye-0.5.1.1, opaleye-0.5.1.0, opaleye-0.5.0.0, opaleye-0.4.2.0,
  opaleye-0.4.1.0, opaleye-0.4.0.0, opaleye-0.3.1.2, opaleye-0.3.1, opaleye-0.3,
  opaleye-0.2, opaleye-0.6.7002.0, opaleye-0.6.7001.0, opaleye-0.6.7000.0,
  opaleye-0.5.2.1, opaleye-0.3.1.1 (has the same characteristics that caused the
  previous version to fail: excluded by constraint '^>=0.7' from example)
  [__1] fail (backjumping, conflict set: example, opaleye)
  After searching the rest of the dependency tree exhaustively, these were the
  goals I've had most trouble fulfilling: opaleye, example
  ```

  There are so many things that are wrong here. Even a sneaky _«to do»_
  remark. If you wonder, in this case the solution is to remove and re-generate
  `cabal.project.freeze`.

  Even the name of the program — it is actually _«cabal-install»_ — is
  incomprehensible, it should be re-branded to Cabal, which is how everyone
  calls it anyway.

* Features are not being introduced.

  There is no reason for two build tools to exist. The killer feature of Stack —
  snapshots — should be supported by Cabal. Possibly Cabal itself should be
  refactored and split so that there are separate tools for packaging, version
  resolution and human interaction — I do not know. But certainly the way things
  are presently is a waste of developer effort and a source of confusion for
  everyone.

### My proposition, in particular.

* Ask all the people that show compassion to the cause of a great Haskell build
  tool to unite and work together on a better Cabal. This includes the
  developers of Stack and everyone that expressed unhappiness with the current
  state of Cabal. These people should be seen as a blessing, not as an obstacle.
* Put in place a clear process for contributing and decision making, so that it
  does not come down to the privileged opinion of one of the core developers.
* Make a model of user experience that Cabal should conform to, and make
  conformance a priority. Surely there are among us people that know a thing or
  two about user experience — call for them to step forward. Every issue that
  stems from misunderstanding, re-assign to the model instead of closing.
* Merge the support of Stackage snapshots into Cabal. Ask the core developers of
  Stack to join the effort. Transition from Stack to Cabal should be one well
  discoverable command that just works.

I realize that this letter is largely an opinion piece. You can also see it as
an _«ideal piece»_. Without an ideal, without a vision, we are stuck with the
present. I do not insist that my vision is the best. But the present reality is
not the best vision either. I propose, foremost, that we work and fight for a
better future.

[1]: https://github.com/commercialhaskell/stackage/issues/4472
[2]: https://github.com/tomjaguarpaw/tilapia/issues?q=is%3Aissue+is%3Aopen+cabal
_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
Reply | Threaded
Open this post in threaded view
|

Re: Do something about Cabal?

Haskell - Haskell-Cafe mailing list
As a still (very) new Haskell user by many measures, indeed the little experience I had with Cabal isn't great overall in my view (honestly not a fan of Stack grabbing separate GHC instances though either unless I pass like 2 command-line flags, if there's a configuration option I'm not aware of I'd be grateful).

I had no clue about the communication issues etc. plaguing Cabal, that explains a bit...

In any case I'd like to try to contribute what I can to this effort, mainly to improve the UX which I agree is absolutely terrible in my humble opinion.

(Side note: I was informed on another mailing list that I may have some setting pertaining to forcing some kind of read receipt which is considered impolite on mailing lists, if this is still the case I apologize and I'm trying to determine what even is the precise issue or setting controlling it, at least on K-9 Mail and Neomutt)

On December 10, 2020 12:23:42 p.m. GMT+01:00, Ignat Insarov <[hidden email]> wrote:

># Do something about Cabal?
>
>Hello.
>
>Cabal is the second most used tool in Haskell after GHC. It has many
>problems. It may be noticed that there is one and a half developers working on
>it. This is clearly not enough to address these problems. I propose that this is
>a good place to invest in.
>
>### Problems I have in mind:
>
>* Poor communication, lack of open source development process.
>
>  The whole Cabal–Stack schism appears to be an outcome of poor
>  communication. One of the leading developers of Cabal is even banned from
>  participation somewhere in Stack circles.[1] Personally, I reported several
>  issues to Cabal and every single time it resulted in sadness. Observe a
>  vicious circle: core developers are overworked ⇒ they are being unfriendly ⇒
>  there are fewer contributors ⇒ core developers are overworked.
>
>  I have no hard evidence but it appears that presently, more people that strive
>  to improve the Haskell build experience are outside the Cabal cabal than are
>  inside.
>
>* User experience is an afterthought.
>
>  Cabal's user experience is horrifying. A collection of complaints is being
>  compiled elsewhere.[2] There are also bugs being opened to Cabal because of
>  this, requiring triage and therefore wasting the precious time of the few
>  overworked developers. Stack is much more friendly — this shows by example
>  that the user experience problem is not inherent and may be solved.
>
>  It is ordinary to receive output like this:
>
>  ```
>  % cabal run example-executable
>  Warning: The package list for 'hackage.haskell.org' is 84 days old.
>  Run 'cabal update' to get the latest list of available packages.
>  Resolving dependencies...
>  cabal: Could not resolve dependencies:
>  [__0] trying: example-0.1.0.6 (user goal)
>  [__1] next goal: opaleye (dependency of example)
>  [__1] rejecting: opaleye-0.7.1.0, opaleye-0.7.0.0 (constraint from project
>  config TODO requires ==0.6.7006.1)
>  [__1] rejecting: opaleye-0.6.7006.1 (conflict: example => opaleye^>=0.7)
>  [__1] skipping: opaleye-0.6.7006.0, opaleye-0.6.7005.0, opaleye-0.6.7004.2,
>  opaleye-0.6.7004.1, opaleye-0.6.7004.0, opaleye-0.6.7003.1,
>  opaleye-0.6.7003.0, opaleye-0.6.1.0, opaleye-0.6.0.0, opaleye-0.5.4.0,
>  opaleye-0.5.3.1, opaleye-0.5.3.0, opaleye-0.5.2.2, opaleye-0.5.2.0,
>  opaleye-0.5.1.1, opaleye-0.5.1.0, opaleye-0.5.0.0, opaleye-0.4.2.0,
>  opaleye-0.4.1.0, opaleye-0.4.0.0, opaleye-0.3.1.2, opaleye-0.3.1, opaleye-0.3,
>  opaleye-0.2, opaleye-0.6.7002.0, opaleye-0.6.7001.0, opaleye-0.6.7000.0,
>  opaleye-0.5.2.1, opaleye-0.3.1.1 (has the same characteristics that caused the
>  previous version to fail: excluded by constraint '^>=0.7' from example)
>  [__1] fail (backjumping, conflict set: example, opaleye)
>  After searching the rest of the dependency tree exhaustively, these were the
>  goals I've had most trouble fulfilling: opaleye, example
>  ```
>
>  There are so many things that are wrong here. Even a sneaky _«to do»_
>  remark. If you wonder, in this case the solution is to remove and re-generate
>  `cabal.project.freeze`.
>
>  Even the name of the program — it is actually _«cabal-install»_ — is
>  incomprehensible, it should be re-branded to Cabal, which is how everyone
>  calls it anyway.
>
>* Features are not being introduced.
>
>  There is no reason for two build tools to exist. The killer feature of Stack —
>  snapshots — should be supported by Cabal. Possibly Cabal itself should be
>  refactored and split so that there are separate tools for packaging, version
>  resolution and human interaction — I do not know. But certainly the way things
>  are presently is a waste of developer effort and a source of confusion for
>  everyone.
>
>### My proposition, in particular.
>
>* Ask all the people that show compassion to the cause of a great Haskell build
>  tool to unite and work together on a better Cabal. This includes the
>  developers of Stack and everyone that expressed unhappiness with the current
>  state of Cabal. These people should be seen as a blessing, not as an obstacle.
>* Put in place a clear process for contributing and decision making, so that it
>  does not come down to the privileged opinion of one of the core developers.
>* Make a model of user experience that Cabal should conform to, and make
>  conformance a priority. Surely there are among us people that know a thing or
>  two about user experience — call for them to step forward. Every issue that
>  stems from misunderstanding, re-assign to the model instead of closing.
>* Merge the support of Stackage snapshots into Cabal. Ask the core developers of
>  Stack to join the effort. Transition from Stack to Cabal should be one well
>  discoverable command that just works.
>
>I realize that this letter is largely an opinion piece. You can also see it as
>an _«ideal piece»_. Without an ideal, without a vision, we are stuck with the
>present. I do not insist that my vision is the best. But the present reality is
>not the best vision either. I propose, foremost, that we work and fight for a
>better future.
>
>[1]: https://github.com/commercialhaskell/stackage/issues/4472
>[2]: https://github.com/tomjaguarpaw/tilapia/issues?q=is%3Aissue+is%3Aopen+cabal
>_______________________________________________
>Haskell-Cafe mailing list
>To (un)subscribe, modify options or view archives go to:
>http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>Only members subscribed via the mailman list are allowed to post.
_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
Reply | Threaded
Open this post in threaded view
|

Re: [HF-discuss] Do something about Cabal?

Francesco Ariis
In reply to this post by Ignat Insarov
Il 10 dicembre 2020 alle 16:23 Ignat Insarov via hf-discuss ha scritto:
> * User experience is an afterthought.
>  […]
> * Features are not being introduced.

I am not a power user, but in the last years — from the
introduction of new- commands — I have enjoyed using cabal very much.
Also each time I download a new version I see small little things added
(a working v2-install, projects, etc.) and updated documentation.

>   There is no reason for two build tools to exist. The killer feature of Stack —
>   snapshots — should be supported by Cabal.

As far as I know, this is already possible today! [1]

>   Personally, I reported several
>   issues to Cabal and every single time it resulted in sadness.

The few time I interacted with cabal/hackage developers — admittedly for
low-complexity issues — they were helpful. In one case some prodding was
necessary (and way less than e.g. with my bank, a service I pay for)
—F

[1] https://github.com/fpco/stackage-server/issues/232
    see also https://github.com/erikd/jenga/
             https://hackage.haskell.org/package/stack2cabal
_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
Reply | Threaded
Open this post in threaded view
|

Re: Do something about Cabal?

Haskell - Haskell-Cafe mailing list
In reply to this post by Ignat Insarov
Personally, when working with Haskell, I miss very much the Gophers' pragmatic attitude in building projects from source, the redundancy of specifications is reduced to extreme where possible, then you usually only need to care about each individual source file. Even with recent [Go Modules](https://golang.org/ref/mod) mechanism, the norm is to edit source files then your `go.mod` file is maintained by tools automatically, you can fix it when auto-updates went wrong, but never have to maintain it yourself. Cabal's principle seems rather cautious in comparison, it worries about you be making mistakes to mis-express your intention by accident, so require warrant of your actions by supplying consistent information allover different places with possibly multiple pieces of submission containing redundant information. It is crucial to need 2 (or more) keys for a nuclear weapon launching panel to be triggerable, but building a project? I think we can take that a lot easier.

I suppose the really hard part of a modern build system is neither compiling/linking nor even project local dependency anymore, it is management of external dependencies now. I'm happy to see Cabal v2 took Nix as the example to follow, but yet there are still huge spaces for improvement in ergonomics respects. I don't expect Haskell/GHC to be that popular like JavaScript/NodeJS, [npm](https://www.npmjs.com/) in a sense may be too successful in ergonomics, that local disk capacity of a developer's machine becomes the sole bottleneck, but there are things definitely improvable after Nix style building modes, so I anticipate a Cabal v3 sooner than later.

Sincerely,
Compl


On 2020-12-10, at 19:23, Ignat Insarov <[hidden email]> wrote:

# Do something about Cabal?

Hello.

Cabal is the second most used tool in Haskell after GHC. It has many
problems. It may be noticed that there is one and a half developers working on
it. This is clearly not enough to address these problems. I propose that this is
a good place to invest in.

### Problems I have in mind:

* Poor communication, lack of open source development process.

 The whole Cabal–Stack schism appears to be an outcome of poor
 communication. One of the leading developers of Cabal is even banned from
 participation somewhere in Stack circles.[1] Personally, I reported several
 issues to Cabal and every single time it resulted in sadness. Observe a
 vicious circle: core developers are overworked ⇒ they are being unfriendly ⇒
 there are fewer contributors ⇒ core developers are overworked.

 I have no hard evidence but it appears that presently, more people that strive
 to improve the Haskell build experience are outside the Cabal cabal than are
 inside.

* User experience is an afterthought.

 Cabal's user experience is horrifying. A collection of complaints is being
 compiled elsewhere.[2] There are also bugs being opened to Cabal because of
 this, requiring triage and therefore wasting the precious time of the few
 overworked developers. Stack is much more friendly — this shows by example
 that the user experience problem is not inherent and may be solved.

 It is ordinary to receive output like this:

 ```
 % cabal run example-executable
 Warning: The package list for 'hackage.haskell.org' is 84 days old.
 Run 'cabal update' to get the latest list of available packages.
 Resolving dependencies...
 cabal: Could not resolve dependencies:
 [__0] trying: example-0.1.0.6 (user goal)
 [__1] next goal: opaleye (dependency of example)
 [__1] rejecting: opaleye-0.7.1.0, opaleye-0.7.0.0 (constraint from project
 config TODO requires ==0.6.7006.1)
 [__1] rejecting: opaleye-0.6.7006.1 (conflict: example => opaleye^>=0.7)
 [__1] skipping: opaleye-0.6.7006.0, opaleye-0.6.7005.0, opaleye-0.6.7004.2,
 opaleye-0.6.7004.1, opaleye-0.6.7004.0, opaleye-0.6.7003.1,
 opaleye-0.6.7003.0, opaleye-0.6.1.0, opaleye-0.6.0.0, opaleye-0.5.4.0,
 opaleye-0.5.3.1, opaleye-0.5.3.0, opaleye-0.5.2.2, opaleye-0.5.2.0,
 opaleye-0.5.1.1, opaleye-0.5.1.0, opaleye-0.5.0.0, opaleye-0.4.2.0,
 opaleye-0.4.1.0, opaleye-0.4.0.0, opaleye-0.3.1.2, opaleye-0.3.1, opaleye-0.3,
 opaleye-0.2, opaleye-0.6.7002.0, opaleye-0.6.7001.0, opaleye-0.6.7000.0,
 opaleye-0.5.2.1, opaleye-0.3.1.1 (has the same characteristics that caused the
 previous version to fail: excluded by constraint '^>=0.7' from example)
 [__1] fail (backjumping, conflict set: example, opaleye)
 After searching the rest of the dependency tree exhaustively, these were the
 goals I've had most trouble fulfilling: opaleye, example
 ```

 There are so many things that are wrong here. Even a sneaky _«to do»_
 remark. If you wonder, in this case the solution is to remove and re-generate
 `cabal.project.freeze`.

 Even the name of the program — it is actually _«cabal-install»_ — is
 incomprehensible, it should be re-branded to Cabal, which is how everyone
 calls it anyway.

* Features are not being introduced.

 There is no reason for two build tools to exist. The killer feature of Stack —
 snapshots — should be supported by Cabal. Possibly Cabal itself should be
 refactored and split so that there are separate tools for packaging, version
 resolution and human interaction — I do not know. But certainly the way things
 are presently is a waste of developer effort and a source of confusion for
 everyone.

### My proposition, in particular.

* Ask all the people that show compassion to the cause of a great Haskell build
 tool to unite and work together on a better Cabal. This includes the
 developers of Stack and everyone that expressed unhappiness with the current
 state of Cabal. These people should be seen as a blessing, not as an obstacle.
* Put in place a clear process for contributing and decision making, so that it
 does not come down to the privileged opinion of one of the core developers.
* Make a model of user experience that Cabal should conform to, and make
 conformance a priority. Surely there are among us people that know a thing or
 two about user experience — call for them to step forward. Every issue that
 stems from misunderstanding, re-assign to the model instead of closing.
* Merge the support of Stackage snapshots into Cabal. Ask the core developers of
 Stack to join the effort. Transition from Stack to Cabal should be one well
 discoverable command that just works.

I realize that this letter is largely an opinion piece. You can also see it as
an _«ideal piece»_. Without an ideal, without a vision, we are stuck with the
present. I do not insist that my vision is the best. But the present reality is
not the best vision either. I propose, foremost, that we work and fight for a
better future.

[1]: https://github.com/commercialhaskell/stackage/issues/4472
[2]: https://github.com/tomjaguarpaw/tilapia/issues?q=is%3Aissue+is%3Aopen+cabal
_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.


_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
Reply | Threaded
Open this post in threaded view
|

Re: [HF-discuss] Do something about Cabal?

Ignat Insarov
In reply to this post by Francesco Ariis
Thanks Francesco. I have also been using Cabal since a long time ago.
There is no question that some great things get done in Cabal. Mostly,
Cabal does what it says on the box, and this is why I propose to
improve it and not, say, move to Stack. But you may see that many
people prefer the latter — this seems even more weird since, as you
illuminate, Cabal can already interoperate with Stackage, so it is
strictly more featureful. _(As far as I follow, Stack still has poor
support for Backpack and sub-package build targets.)_

However, even in the light of the links you provide, we still cannot
say that Cabal supports Stackage. You say:

> >   There is no reason for two build tools to exist. The killer feature of Stack —
> >   snapshots — should be supported by Cabal.
>
> As far as I know, this is already possible today! [1]
>
> [1] https://github.com/fpco/stackage-server/issues/232
>     see also https://github.com/erikd/jenga/
>              https://hackage.haskell.org/package/stack2cabal

Heading to that link, the closing message says:

> I've added a warning about the lack of support for revisions in cabal.config in f9632d7. Closing.

So, something is not working. Reading in more detail, there is
evidently a disagreement between the core developers of Cabal and
Stack. And as I understand, it has not been addressed ever since! This
is exactly an example of the kind of communication problems that I
alluded to in my first letter. Also, as far as I can see, there has
been zero effort from the Cabal team to integrate these other tools
that you point to.
_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
Reply | Threaded
Open this post in threaded view
|

Re: [HF-discuss] Do something about Cabal?

J Ho
What's wrong with Stack though? Works like a charm in all our projects, and with Nix integration takes care of the external c-libs etc dependencies quite nicely. 

On Thu, Dec 10, 2020 at 3:07 PM Ignat Insarov <[hidden email]> wrote:
Thanks Francesco. I have also been using Cabal since a long time ago.
There is no question that some great things get done in Cabal. Mostly,
Cabal does what it says on the box, and this is why I propose to
improve it and not, say, move to Stack. But you may see that many
people prefer the latter — this seems even more weird since, as you
illuminate, Cabal can already interoperate with Stackage, so it is
strictly more featureful. _(As far as I follow, Stack still has poor
support for Backpack and sub-package build targets.)_

However, even in the light of the links you provide, we still cannot
say that Cabal supports Stackage. You say:

> >   There is no reason for two build tools to exist. The killer feature of Stack —
> >   snapshots — should be supported by Cabal.
>
> As far as I know, this is already possible today! [1]
>
> [1] https://github.com/fpco/stackage-server/issues/232
>     see also https://github.com/erikd/jenga/
>              https://hackage.haskell.org/package/stack2cabal

Heading to that link, the closing message says:

> I've added a warning about the lack of support for revisions in cabal.config in f9632d7. Closing.

So, something is not working. Reading in more detail, there is
evidently a disagreement between the core developers of Cabal and
Stack. And as I understand, it has not been addressed ever since! This
is exactly an example of the kind of communication problems that I
alluded to in my first letter. Also, as far as I can see, there has
been zero effort from the Cabal team to integrate these other tools
that you point to.
_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.

_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
Reply | Threaded
Open this post in threaded view
|

Re: [HF-discuss] Do something about Cabal?

Dmitrii Kovanikov
In reply to this post by Ignat Insarov
Thanks, Ignat for bringing this issue! This is indeed a problem in the Haskell community and ecosystem at the moment, and we can't just ignore it if we want to improve things.

Every Haskell developer uses the build tool. This is a crucial piece of development toolchain. That's why it's sad if a core tool is maintained only by a single person, maintainers are not willing to have more open-minded discussions regarding some user-requested features or a tool have poor UX. In my vision, everyone should be welcome to open issues to a build tool and contribute to it as everyone will benefit from improvements. And it's a pity that some people have a negative experience with this process which drives contributors away. I'm following the Cabal issue tracker, so I notice from time to time some not friendly behaviour towards its users.

In the same spirit, having multiple build tools leads to duplication of effort for fixing the same problems and implementing the same features. Writing a build tool requires a colossal amount of effort and time. Not to mention that supporting both build tools is an enormous job as well. 

* If your project builds with Cabal, it's not guaranteed to build with Stack (at least you need to write stack.yaml). 
* If your project builds with Stack, it's not guaranteed to build with Cabal (you may need to specify upper and lower bounds). 

Thus, every maintainer must spend a lot of time maintaining support for both build tools if they want to provide good UX for everyone. I'm doing this for multiple years, and it's a troublesome process, but I do believe that thinking about users first is the way forward. This effort seems redundant in a theoretical world where Haskell has a single, core, official, open-sourced build tool managed by the community. 

> I have enjoyed using cabal very much

I'm also using Cabal for my personal projects, but this doesn't mean there are no problems. I learned to circumvent build tools pitfalls and survive in the ocean of incomprehensible errors, but I'm already in the middle of the ocean, and I don't want to stop swimming. Beginners, who are just staying on the coast, might not want to go into it at all.

Best,
Dmitrii



On Thu, 10 Dec 2020 at 14:06, Ignat Insarov via hf-discuss <[hidden email]> wrote:
Thanks Francesco. I have also been using Cabal since a long time ago.
There is no question that some great things get done in Cabal. Mostly,
Cabal does what it says on the box, and this is why I propose to
improve it and not, say, move to Stack. But you may see that many
people prefer the latter — this seems even more weird since, as you
illuminate, Cabal can already interoperate with Stackage, so it is
strictly more featureful. _(As far as I follow, Stack still has poor
support for Backpack and sub-package build targets.)_

However, even in the light of the links you provide, we still cannot
say that Cabal supports Stackage. You say:

> >   There is no reason for two build tools to exist. The killer feature of Stack —
> >   snapshots — should be supported by Cabal.
>
> As far as I know, this is already possible today! [1]
>
> [1] https://github.com/fpco/stackage-server/issues/232
>     see also https://github.com/erikd/jenga/
>              https://hackage.haskell.org/package/stack2cabal

Heading to that link, the closing message says:

> I've added a warning about the lack of support for revisions in cabal.config in f9632d7. Closing.

So, something is not working. Reading in more detail, there is
evidently a disagreement between the core developers of Cabal and
Stack. And as I understand, it has not been addressed ever since! This
is exactly an example of the kind of communication problems that I
alluded to in my first letter. Also, as far as I can see, there has
been zero effort from the Cabal team to integrate these other tools
that you point to.
_______________________________________________
hf-discuss mailing list
[hidden email]
https://mail.haskell.org/cgi-bin/mailman/listinfo/hf-discuss

_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
Reply | Threaded
Open this post in threaded view
|

Re: [HF-discuss] Do something about Cabal?

Richard Eisenberg-5
In reply to this post by Haskell - Haskell-Cafe mailing list
In my view, a lack of communication like the one highlighted here is exactly what the Haskell Foundation hopes to improve. It's still being bootstrapped, so don't expect any action soon, but I would hope for forward motion by the springtime.

Of course, the HF needs all of us to be the best foundation it can -- so please consider nominating yourself for a board position (https://haskell.foundation/board-nominations/) and/or applying for the executive director (full-time, salaried) position (https://haskell.foundation/ed-job-description/)! In either role, you could have direct impact on moving this all forward.

Richard

On Dec 10, 2020, at 6:42 AM, Allen Sobot via hf-discuss <[hidden email]> wrote:

As a still (very) new Haskell user by many measures, indeed the little experience I had with Cabal isn't great overall in my view (honestly not a fan of Stack grabbing separate GHC instances though either unless I pass like 2 command-line flags, if there's a configuration option I'm not aware of I'd be grateful).

I had no clue about the communication issues etc. plaguing Cabal, that explains a bit...

In any case I'd like to try to contribute what I can to this effort, mainly to improve the UX which I agree is absolutely terrible in my humble opinion.

(Side note: I was informed on another mailing list that I may have some setting pertaining to forcing some kind of read receipt which is considered impolite on mailing lists, if this is still the case I apologize and I'm trying to determine what even is the precise issue or setting controlling it, at least on K-9 Mail and Neomutt)

On December 10, 2020 12:23:42 p.m. GMT+01:00, Ignat Insarov <[hidden email]> wrote:
# Do something about Cabal?

Hello.

Cabal is the second most used tool in Haskell after GHC. It has many
problems. It may be noticed that there is one and a half developers working on
it. This is clearly not enough to address these problems. I propose that this is
a good place to invest in.

### Problems I have in mind:

* Poor communication, lack of open source development process.

The whole Cabal–Stack schism appears to be an outcome of poor
communication. One of the leading developers of Cabal is even banned from
participation somewhere in Stack circles.[1] Personally, I reported several
issues to Cabal and every single time it resulted in sadness. Observe a
vicious circle: core developers are overworked ⇒ they are being unfriendly ⇒
there are fewer contributors ⇒ core developers are overworked.

I have no hard evidence but it appears that presently, more people that strive
to improve the Haskell build experience are outside the Cabal cabal than are
inside.

* User experience is an afterthought.

Cabal's user experience is horrifying. A collection of complaints is being
compiled elsewhere.[2] There are also bugs being opened to Cabal because of
this, requiring triage and therefore wasting the precious time of the few
overworked developers. Stack is much more friendly — this shows by example
that the user experience problem is not inherent and may be solved.

It is ordinary to receive output like this:

```
% cabal run example-executable
Warning: The package list for 'hackage.haskell.org' is 84 days old.
Run 'cabal update' to get the latest list of available packages.
Resolving dependencies...
cabal: Could not resolve dependencies:
[__0] trying: example-0.1.0.6 (user goal)
[__1] next goal: opaleye (dependency of example)
[__1] rejecting: opaleye-0.7.1.0, opaleye-0.7.0.0 (constraint from project
config TODO requires ==0.6.7006.1)
[__1] rejecting: opaleye-0.6.7006.1 (conflict: example => opaleye^>=0.7)
[__1] skipping: opaleye-0.6.7006.0, opaleye-0.6.7005.0, opaleye-0.6.7004.2,
opaleye-0.6.7004.1, opaleye-0.6.7004.0, opaleye-0.6.7003.1,
opaleye-0.6.7003.0, opaleye-0.6.1.0, opaleye-0.6.0.0, opaleye-0.5.4.0,
opaleye-0.5.3.1, opaleye-0.5.3.0, opaleye-0.5.2.2, opaleye-0.5.2.0,
opaleye-0.5.1.1, opaleye-0.5.1.0, opaleye-0.5.0.0, opaleye-0.4.2.0,
opaleye-0.4.1.0, opaleye-0.4.0.0, opaleye-0.3.1.2, opaleye-0.3.1, opaleye-0.3,
opaleye-0.2, opaleye-0.6.7002.0, opaleye-0.6.7001.0, opaleye-0.6.7000.0,
opaleye-0.5.2.1, opaleye-0.3.1.1 (has the same characteristics that caused the
previous version to fail: excluded by constraint '^>=0.7' from example)
[__1] fail (backjumping, conflict set: example, opaleye)
After searching the rest of the dependency tree exhaustively, these were the
goals I've had most trouble fulfilling: opaleye, example
```

There are so many things that are wrong here. Even a sneaky _«to do»_
remark. If you wonder, in this case the solution is to remove and re-generate
`cabal.project.freeze`.

Even the name of the program — it is actually _«cabal-install»_ — is
incomprehensible, it should be re-branded to Cabal, which is how everyone
calls it anyway.

* Features are not being introduced.

There is no reason for two build tools to exist. The killer feature of Stack —
snapshots — should be supported by Cabal. Possibly Cabal itself should be
refactored and split so that there are separate tools for packaging, version
resolution and human interaction — I do not know. But certainly the way things
are presently is a waste of developer effort and a source of confusion for
everyone.

### My proposition, in particular.

* Ask all the people that show compassion to the cause of a great Haskell build
tool to unite and work together on a better Cabal. This includes the
developers of Stack and everyone that expressed unhappiness with the current
state of Cabal. These people should be seen as a blessing, not as an obstacle.
* Put in place a clear process for contributing and decision making, so that it
does not come down to the privileged opinion of one of the core developers.
* Make a model of user experience that Cabal should conform to, and make
conformance a priority. Surely there are among us people that know a thing or
two about user experience — call for them to step forward. Every issue that
stems from misunderstanding, re-assign to the model instead of closing.
* Merge the support of Stackage snapshots into Cabal. Ask the core developers of
Stack to join the effort. Transition from Stack to Cabal should be one well
discoverable command that just works.

I realize that this letter is largely an opinion piece. You can also see it as
an _«ideal piece»_. Without an ideal, without a vision, we are stuck with the
present. I do not insist that my vision is the best. But the present reality is
not the best vision either. I propose, foremost, that we work and fight for a
better future.

[1]: https://github.com/commercialhaskell/stackage/issues/4472
[2]: https://github.com/tomjaguarpaw/tilapia/issues?q=is%3Aissue+is%3Aopen+cabal
_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
_______________________________________________
hf-discuss mailing list
[hidden email]
https://mail.haskell.org/cgi-bin/mailman/listinfo/hf-discuss


_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
Reply | Threaded
Open this post in threaded view
|

Re: [HF-discuss] Do something about Cabal?

Haskell - Haskell-Cafe mailing list
In reply to this post by J Ho

Both tools have deficiencies, but looking at the "10 year overnight success" that is the recent step-change in the quality of Haskell's Language Server Protocol support, I am hopeful for the future. The answer is not as simple as "just use stack" or "just use cabal-install". I do not want to kick off a build-tool flamewar, but neither cabal-install nor stack are magical Christmas lands where everything is perfect. Here are a collection of objections to/my frustrations with stack, which is why "just use stack" isn't an answer to the problem:

- Can't do GHCjs
- Seems to like mass-rebuilding my work projects if I breathe on them the wrong way
- Has its own way of doing everything that's slightly different (different command set, different ways of specifying build targets)
- Fails to give me a REPL if it can't load all of a target's files first (I'm not sure exactly what's going on here, but when using dante, stack will blow up if the project contains a type error somewhere. Which is unhelpful when trying to get interactive editor support to resolve said type errors! Dante driving cabal does not have this problem. Extremely frustrating.)
- Haskell programmers tend to end up coding to the lowest common subset of features across build tools. This held back adoption of backpack, which is sad.
- hpack-by-default pushes another reinvention of basic haskell tooling, and does so with YAML, which is a file format that gets worse the more you understand it. (I expect its defenders will say this is just providing an option, but from my experience onboarding new Hackage uploaders, many people do not realise that hpack is optional.)
- Many stack projects do not provide bounds on dependencies, relying on getting exact versions from LTS. This may be defensible for applications that sit at the leaves of a dependency graph, but less so for libraries. Accurate bound information is one of the reasons LTS build plans can be easily constructed, and tooling that encourages sloppy bounds feels to me like it encourages taking without giving back to the shared resource (the common set of libraries on Hackage with well-understood bounds).
- What is casa.fpcomplete.com, and why was its downtime causing CI failures in my projects? What does stack talk to that domain about?

HTH,

-- Jack

December 11, 2020 12:17 AM, "J Ho via hf-discuss" <[hidden email]> wrote:

> What's wrong with Stack though? Works like a charm in all our projects, and with Nix integration
> takes care of the external c-libs etc dependencies quite nicely.
>
> On Thu, Dec 10, 2020 at 3:07 PM Ignat Insarov <[hidden email]> wrote:
>
>> Thanks Francesco. I have also been using Cabal since a long time ago.
>> There is no question that some great things get done in Cabal. Mostly,
>> Cabal does what it says on the box, and this is why I propose to
>> improve it and not, say, move to Stack. But you may see that many
>> people prefer the latter — this seems even more weird since, as you
>> illuminate, Cabal can already interoperate with Stackage, so it is
>> strictly more featureful. _(As far as I follow, Stack still has poor
>> support for Backpack and sub-package build targets.)_
>>
>> However, even in the light of the links you provide, we still cannot
>> say that Cabal supports Stackage. You say:
>>
>>>> There is no reason for two build tools to exist. The killer feature of Stack —
>>>> snapshots — should be supported by Cabal.
>>>
>>> As far as I know, this is already possible today! [1]
>>>
>>> [1] https://github.com/fpco/stackage-server/issues/232
>>> see also https://github.com/erikd/jenga/
>>> https://hackage.haskell.org/package/stack2cabal
>>
>> Heading to that link, the closing message says:
>>
>>> I've added a warning about the lack of support for revisions in cabal.config in f9632d7. Closing.
>>
>> So, something is not working. Reading in more detail, there is
>> evidently a disagreement between the core developers of Cabal and
>> Stack. And as I understand, it has not been addressed ever since! This
>> is exactly an example of the kind of communication problems that I
>> alluded to in my first letter. Also, as far as I can see, there has
>> been zero effort from the Cabal team to integrate these other tools
>> that you point to.
>> _______________________________________________
>> Haskell-Cafe mailing list
>> To (un)subscribe, modify options or view archives go to:
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>> Only members subscribed via the mailman list are allowed to post.
_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
Reply | Threaded
Open this post in threaded view
|

Re: Do something about Cabal?

Viktor Dukhovni
In reply to this post by Ignat Insarov
On Thu, Dec 10, 2020 at 04:23:42PM +0500, Ignat Insarov wrote:

> * User experience is an afterthought.

I don't think that's fair. Making/keeping the simple things easy,
without making the complex things impossible is always a challenge.

Yes, starting a hello-world project should admittedly be one command
with fewer required options.  Presently, it is:

    $ mkdir hello
    $ cd hello
    $ cabal init --cabal-version=2.4 --license=NONE -p helloworld

but this is not the primary barrier to Cabal's usability.

Like many a tool that has evolved over decades, and supports backwards
compatible historical practices, Cabal exposes more complexity and rough
edges than much more recent toolchains that don't share than burden.

Give me Cabal over Debian packages any day...

>   Cabal's user experience is horrifying. 

It is likely that use of strident terms like "horrifying" does not
further the kind of community building that this message aims to
achieve. :-(

Indeed cabal was fairly intimidating when I started out, and for a long
time I used stack.  More recently I've switched to cabal, as a more
flexible power tool.  And yet some workflows, e.g. involving internal
libraries, custom builds, code generation, doctest integration, ...
remain challenging to figure out.  On the whole, I've seen much progress
over the last few years.

>   It is ordinary to receive output like this:
>
>   cabal: Could not resolve dependencies:

I would posit that this is the main obstacle facing most users, and is
largely not Cabal's fault.  Rather it is a key property of the Hackage
ecosystem that libraries can and do make incompatible changes across
major version bumps, and that when one chooses a sufficiently new GHC
or elects a sufficiently new feature of some library, the rest of the
ecosystem may not yet be manifestly compatible with that choice.

Stack side-steps the problem by freezing the compiler, base and most
dependencies.  This is often convenient, but is not always what you
want.

I don't see a high likelihood of a second community effort that produces
LTS-style snapshots for cabal, nor that the Cabal and stack teams goals
will align sufficiently to make the snapshot definitions a shared
resource.  Perhaps I'm too cynical, but I think that's the realistic
assessment.

> ### My proposition, in particular.
>
> * Ask all the people that show compassion to the cause of a great Haskell build
>   tool to unite and work together on a better Cabal. This includes the
>   developers of Stack and everyone that expressed unhappiness with the current
>   state of Cabal. These people should be seen as a blessing, not as an obstacle.

This post seems unlikely to lead to that outcome...  It has probably
already started off on the wrong foot, by being more strident than
constructive.

It all probability reuniting development efforts that have parted ways
is not possible.  All that can happen is that some, but ideally not all
will wither away.  Nobody has succeeded in reuniting NetBSD, OpenBSD and
FreeBSD.  Not to mention the many Linux distributions, screen vs. tmux,
GCC vs. LLVM, KDE vs. Gnome, ...

More realistically, contributors to Cabal willing to devote time and
energy to improving it will add the features that they care about most.
Perhaps now and then someone will step up to *fund* development of some
crucial feature that no volunteer is likely to build on their own
accord.  It all largely boils down to resources, and the fact that
volunteers will work on what most interests them, and there's no
benevolent dictator able to set a global agenda.

--
    Viktor.
_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
Reply | Threaded
Open this post in threaded view
|

Re: Do something about Cabal?

Joachim Durchholz
Am 10.12.20 um 23:53 schrieb Viktor Dukhovni:
> It all probability reuniting development efforts that have parted ways
> is not possible.  All that can happen is that some, but ideally not all
> will wither away.  Nobody has succeeded in reuniting NetBSD, OpenBSD and
> FreeBSD.  Not to mention the many Linux distributions, screen vs. tmux,
> GCC vs. LLVM, KDE vs. Gnome, ...

Ah, that's a bit of survivor bias. Forked libraries and tools re-join
all the time.
It's not the standard outcome, of course, but I read reports of such
rejoins often enough that I'd consider the phrase "all that can happen"
to be too strong to applicable.

Regards,
Jo
_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
Reply | Threaded
Open this post in threaded view
|

Re: [HF-discuss] Do something about Cabal?

Haskell - Haskell-Cafe mailing list
In reply to this post by Haskell - Haskell-Cafe mailing list
Just my 2 cents of thoughts, no tool can be perfect, as human individuals. If the Haskell ecosystem can be considered a public asset of all users, contributors, it is not wise for us as the stakeholders to be adverse  of competition. Just imagine the government allowing a single military contractor to monopolize a whole category of weapons, what would come after?

Innovation and advancing comes after competition, why shouldn't we embrace that wrt the tooling of Haskell? Duplication in efforts is a relative smaller problem IMHO.

Sincerely,
Compl


> On 2020-12-11, at 05:07, Jack Kelly via Haskell-Cafe <[hidden email]> wrote:
>
>
> Both tools have deficiencies, but looking at the "10 year overnight success" that is the recent step-change in the quality of Haskell's Language Server Protocol support, I am hopeful for the future. The answer is not as simple as "just use stack" or "just use cabal-install". I do not want to kick off a build-tool flamewar, but neither cabal-install nor stack are magical Christmas lands where everything is perfect. Here are a collection of objections to/my frustrations with stack, which is why "just use stack" isn't an answer to the problem:
>
> - Can't do GHCjs
> - Seems to like mass-rebuilding my work projects if I breathe on them the wrong way
> - Has its own way of doing everything that's slightly different (different command set, different ways of specifying build targets)
> - Fails to give me a REPL if it can't load all of a target's files first (I'm not sure exactly what's going on here, but when using dante, stack will blow up if the project contains a type error somewhere. Which is unhelpful when trying to get interactive editor support to resolve said type errors! Dante driving cabal does not have this problem. Extremely frustrating.)
> - Haskell programmers tend to end up coding to the lowest common subset of features across build tools. This held back adoption of backpack, which is sad.
> - hpack-by-default pushes another reinvention of basic haskell tooling, and does so with YAML, which is a file format that gets worse the more you understand it. (I expect its defenders will say this is just providing an option, but from my experience onboarding new Hackage uploaders, many people do not realise that hpack is optional.)
> - Many stack projects do not provide bounds on dependencies, relying on getting exact versions from LTS. This may be defensible for applications that sit at the leaves of a dependency graph, but less so for libraries. Accurate bound information is one of the reasons LTS build plans can be easily constructed, and tooling that encourages sloppy bounds feels to me like it encourages taking without giving back to the shared resource (the common set of libraries on Hackage with well-understood bounds).
> - What is casa.fpcomplete.com, and why was its downtime causing CI failures in my projects? What does stack talk to that domain about?
>
> HTH,
>
> -- Jack
>
> December 11, 2020 12:17 AM, "J Ho via hf-discuss" <[hidden email]> wrote:
>
>> What's wrong with Stack though? Works like a charm in all our projects, and with Nix integration
>> takes care of the external c-libs etc dependencies quite nicely.
>>
>> On Thu, Dec 10, 2020 at 3:07 PM Ignat Insarov <[hidden email]> wrote:
>>
>>> Thanks Francesco. I have also been using Cabal since a long time ago.
>>> There is no question that some great things get done in Cabal. Mostly,
>>> Cabal does what it says on the box, and this is why I propose to
>>> improve it and not, say, move to Stack. But you may see that many
>>> people prefer the latter — this seems even more weird since, as you
>>> illuminate, Cabal can already interoperate with Stackage, so it is
>>> strictly more featureful. _(As far as I follow, Stack still has poor
>>> support for Backpack and sub-package build targets.)_
>>>
>>> However, even in the light of the links you provide, we still cannot
>>> say that Cabal supports Stackage. You say:
>>>
>>>>> There is no reason for two build tools to exist. The killer feature of Stack —
>>>>> snapshots — should be supported by Cabal.
>>>>
>>>> As far as I know, this is already possible today! [1]
>>>>
>>>> [1] https://github.com/fpco/stackage-server/issues/232
>>>> see also https://github.com/erikd/jenga/
>>>> https://hackage.haskell.org/package/stack2cabal
>>>
>>> Heading to that link, the closing message says:
>>>
>>>> I've added a warning about the lack of support for revisions in cabal.config in f9632d7. Closing.
>>>
>>> So, something is not working. Reading in more detail, there is
>>> evidently a disagreement between the core developers of Cabal and
>>> Stack. And as I understand, it has not been addressed ever since! This
>>> is exactly an example of the kind of communication problems that I
>>> alluded to in my first letter. Also, as far as I can see, there has
>>> been zero effort from the Cabal team to integrate these other tools
>>> that you point to.
>>> _______________________________________________
>>> Haskell-Cafe mailing list
>>> To (un)subscribe, modify options or view archives go to:
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
>>> Only members subscribed via the mailman list are allowed to post.
> _______________________________________________
> Haskell-Cafe mailing list
> To (un)subscribe, modify options or view archives go to:
> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
> Only members subscribed via the mailman list are allowed to post.

_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
Reply | Threaded
Open this post in threaded view
|

Re: [HF-discuss] Do something about Cabal?

Immanuel Litzroth-2
I found the whole cabal experience confusing and not well documented.
I kept finding blogs online
that were not working anymore in my version of cabal ('cabal sandbox
init', 'cabal init --sandbox'...) when looking
for advice. I still don't understand the whole v1-build, v2-build,
new-build and build...
The manual doesn't seem to have a decent conceptual overview of what
the tool should do (e.g. an explanation
of what sandboxing is supposed to achieve, or the 4 build command versions).
Several of the links on this page https://www.haskell.org/cabal/  are dead
https://www.haskell.org/cabal/release/cabal-latest/doc/API/Cabal/
or refer to old versions:
https://wiki.haskell.org/Upgrading_packages

This should not be construed as a critique of what has been achieved,
but as honest feedback
of my experience.
> Innovation and advancing comes after competition, why shouldn't we embrace that wrt the tooling of Haskell? Duplication in efforts is a relative smaller problem IMHO.
Well the competition has "go build" and cargo...
And duplication of effort is a problem when there's not enough
resources for even one decent build tool
Immanuel
_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
Reply | Threaded
Open this post in threaded view
|

Re: [HF-discuss] Do something about Cabal?

Bardur Arantsson-2
In reply to this post by Haskell - Haskell-Cafe mailing list
On 10/12/2020 22.07, Jack Kelly via Haskell-Cafe wrote:
>
> Both tools have deficiencies, but looking at the "10 year overnight success" that is the recent step-change in the quality of Haskell's Language Server Protocol support, I am hopeful for the future. The answer is not as simple as "just use stack" or "just use cabal-install". I do not want to kick off a build-tool flamewar, but neither cabal-install nor stack are magical Christmas lands where everything is perfect. Here are a collection of objections to/my frustrations with stack, which is why "just use stack" isn't an answer to the problem:
>
[--snip--]

Absolutely agreed that there is currently to "Right Answer"(TM) wrt.
Cabal or Stack. They do different things well/badly. Until we get a tool
that can do everything the schism will probably remain.

(And that's not even talking about issues like technical debt in each of
the code bases, etc.)

Anyway, just wanted to comment on a couple of points:

> - hpack-by-default pushes another reinvention of basic haskell tooling, and does so with YAML, which is a file format that gets worse the more you understand it. (I expect its defenders will say this is just providing an option, but from my experience onboarding new Hackage uploaders, many people do not realise that hpack is optional.)

My problem here is that Cabal hasn't provided some very useful the
features that YAML does out of the box, namely the ability to define
arbitrary snippets of package configuration and to refer to them from
multiple places. Examples:

If I maintain a cohesive set of 5 packages, I need to duplicate various
bits and bobs of information in 5 different places:

  - author info, license info
  - ghc options (I like to use identical options for all my packages in
a 'set')
  - dependency version ranges(!)

in 5 different cabal files. This is tedious at best and outright wrong
at worst (inconsistent version bounds). YAML lets me avoid that
annoyance -- yes, using entities and entity refs is a hackish way to do
it, but it *works*.

In no way am I advocating for YAML specifically. IMO, it's absurdly
complex to cater for the needs of <1% of its users. However, I do wish
Cabal could use some standardized format with similar capabilites for
avoiding duplication in a full *generic* way.

My problem with the cabal file format is that is basically entirely
ad-hoc, esp. wrt. what I can avoid repeating over and over.

(Dhall could work here since you can at least do inclusions and reuse in
a generic way. Plus it has fully defined semantics plus implementations
in at least a couple of langauges, Haskell and Scala.)

> - Many stack projects do not provide bounds on dependencies, relying on getting exact versions from LTS. This may be defensible for applications that sit at the leaves of a dependency graph, but less so for libraries. Accurate bound information is one of the reasons LTS build plans can be easily constructed, and tooling that encourages sloppy bounds feels to me like it encourages taking without giving back to the shared resource (the common set of libraries on Hackage with well-understood bounds).

I posit that at least a *part* of the problem here is tedium for
maintainers (see above), but while we're at it: I'm not sure manually
maintaining bounds is at all scalable nor particularly "correct" (for
lower bounds, esp.) unless one is *super*-vigilant about what bits of a
dependency are *actually* in use.

FWIW, I do try to do this for my packages, but I'm very confident that
all of my packages probably have misleading lower bounds.

It seems to me that some automated tooling is needed here, e.g. to try
building/testing with e.g. all deps at the lower bound, all deps at the
highest bound, etc.

Regards,

_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
Reply | Threaded
Open this post in threaded view
|

Re: [HF-discuss] Do something about Cabal?

Oliver Charles-3
On Fri, 11 Dec 2020, at 9:50 AM, Bardur Arantsson wrote:
(Dhall could work here since you can at least do inclusions and reuse in
a generic way. Plus it has fully defined semantics plus implementations
in at least a couple of langauges, Haskell and Scala.)


I think the missing piece here is making a frontend that transparently turns Dhall to Cabal syntax and runs cabal-install, so you don't have to keep regenerating files.

Ollie

_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
Reply | Threaded
Open this post in threaded view
|

Re: [HF-discuss] Do something about Cabal?

Bardur Arantsson-2
On 11/12/2020 10.56, Oliver Charles wrote:
> On Fri, 11 Dec 2020, at 9:50 AM, Bardur Arantsson wrote:
>> (Dhall could work here since you can at least do inclusions and reuse in
>> a generic way. Plus it has fully defined semantics plus implementations
>> in at least a couple of langauges, Haskell and Scala.)
>
> Psst https://hackage.haskell.org/package/dhall-to-cabal
> <https://hackage.haskell.org/package/dhall-to-cabal> :)
>

Yes, thank for pointing that out :). I think I actually tried it at one
point, but it was way to immature at the time... must have slipped my
mind since then.

IIRC my major problem at the time I tried it, it was also *really* slow.
I mean "minutes" rather than "seconds" slow.

I think that may have been due to performance problems in the Haskell
implementation of Dhall, so hopefully it's not an issue these days.

(It might also have been PEBKAC on my part, it's all a bit fuzzy...)

> I think the missing piece here is making a frontend that transparently
> turns Dhall to Cabal syntax and runs cabal-install, so you don't ha ve
> to keep regenerating files.
>

That would be nice, but for large-scale adoption I think it probably
needs to actually be an *official* format and perhaps even be upstreamed
so that it gets maintained along with the Cabal format. (To account for
things that change semi-often like extension names, new cabal settings,
and whatnot.) Plus to know that it will be maintained well into the future.

Thanks for working on it, btw. Might give it a shop when I get tired of
hpack/YAML :).

Regards,

_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
Reply | Threaded
Open this post in threaded view
|

Re: [HF-discuss] Do something about Cabal?

Yasuaki Kudo
In reply to this post by Oliver Charles-3
Hi!

I have not done any serious programming in Haskell (although at some point I would love to 😄) , I am interested in this topic, because this is one of the first obstacles of using it...

I wonder if it's possible to appropriate GNU Guix as the distribution channel of many libraries.

I heard it is now an experimental package in Debian😄 https://packages.debian.org/experimental/guix

(FYI - After experimenting with both NixOS and Guix recently and I decided to favor Guix - but I notice Stack already has Integration with Nix?)

And here is the Guix packaging guide I found for Python

Cheers,
Yasu


On Dec 11, 2020, at 18:57, Oliver Charles <[hidden email]> wrote:


On Fri, 11 Dec 2020, at 9:50 AM, Bardur Arantsson wrote:
(Dhall could work here since you can at least do inclusions and reuse in
a generic way. Plus it has fully defined semantics plus implementations
in at least a couple of langauges, Haskell and Scala.)


I think the missing piece here is making a frontend that transparently turns Dhall to Cabal syntax and runs cabal-install, so you don't have to keep regenerating files.

Ollie
_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.

_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
Reply | Threaded
Open this post in threaded view
|

Re: [HF-discuss] Do something about Cabal?

Oliver Charles-3
In reply to this post by Bardur Arantsson-2
On Fri, 11 Dec 2020, at 10:07 AM, Bardur Arantsson wrote:
On 11/12/2020 10.56, Oliver Charles wrote:
> On Fri, 11 Dec 2020, at 9:50 AM, Bardur Arantsson wrote:
>> (Dhall could work here since you can at least do inclusions and reuse in
>> a generic way. Plus it has fully defined semantics plus implementations
>> in at least a couple of langauges, Haskell and Scala.)



Yes, thank for pointing that out :). I think I actually tried it at one
point, but it was way to immature at the time... must have slipped my
mind since then.

IIRC my major problem at the time I tried it, it was also *really* slow.
I mean "minutes" rather than "seconds" slow.

I think that may have been due to performance problems in the Haskell
implementation of Dhall, so hopefully it's not an issue these days.

Yes, it was due to performance problems with Dhall itself. This project actually helped act as a benchmark for us to improve Dhall. I think things should be much better now. I have unfortunately all-but-abandoned the project because there are no users, including myself. But it's still there and I think there's still a lot of useful work there.

_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
Reply | Threaded
Open this post in threaded view
|

Re: Do something about Cabal?

Alberto G. Corona
In reply to this post by Ignat Insarov
I played some time ago with a "brute force" building tool which starts only from the includes of the main source file. It tried to find the packages for these modules using the google search service to search in Hackage, download the package sources from Hackage and added the packages  as options to the ghc -ipackage1 ipackage2   command line, recursively. If some error happened I tried with the files of an older version for the package that produced the error, by parsing the GHC errors. It failed at some C import libraries but at this moment it can be switched to build in cabal or stack mode for that package/module.

I write this just in case this gives some ideas to someone to go along these lines.

Much of that is what Cabal does anyway, but constrained by the limits imposed by the *.cabal files in the packages. But the machinery is there
Perhaps Cabal could have a --bruteforce  option?

El jue, 10 dic 2020 a las 12:25, Ignat Insarov (<[hidden email]>) escribió:
# Do something about Cabal?

Hello.

Cabal is the second most used tool in Haskell after GHC. It has many
problems. It may be noticed that there is one and a half developers working on
it. This is clearly not enough to address these problems. I propose that this is
a good place to invest in.

### Problems I have in mind:

* Poor communication, lack of open source development process.

  The whole Cabal–Stack schism appears to be an outcome of poor
  communication. One of the leading developers of Cabal is even banned from
  participation somewhere in Stack circles.[1] Personally, I reported several
  issues to Cabal and every single time it resulted in sadness. Observe a
  vicious circle: core developers are overworked ⇒ they are being unfriendly ⇒
  there are fewer contributors ⇒ core developers are overworked.

  I have no hard evidence but it appears that presently, more people that strive
  to improve the Haskell build experience are outside the Cabal cabal than are
  inside.

* User experience is an afterthought.

  Cabal's user experience is horrifying. A collection of complaints is being
  compiled elsewhere.[2] There are also bugs being opened to Cabal because of
  this, requiring triage and therefore wasting the precious time of the few
  overworked developers. Stack is much more friendly — this shows by example
  that the user experience problem is not inherent and may be solved.

  It is ordinary to receive output like this:

  ```
  % cabal run example-executable
  Warning: The package list for 'hackage.haskell.org' is 84 days old.
  Run 'cabal update' to get the latest list of available packages.
  Resolving dependencies...
  cabal: Could not resolve dependencies:
  [__0] trying: example-0.1.0.6 (user goal)
  [__1] next goal: opaleye (dependency of example)
  [__1] rejecting: opaleye-0.7.1.0, opaleye-0.7.0.0 (constraint from project
  config TODO requires ==0.6.7006.1)
  [__1] rejecting: opaleye-0.6.7006.1 (conflict: example => opaleye^>=0.7)
  [__1] skipping: opaleye-0.6.7006.0, opaleye-0.6.7005.0, opaleye-0.6.7004.2,
  opaleye-0.6.7004.1, opaleye-0.6.7004.0, opaleye-0.6.7003.1,
  opaleye-0.6.7003.0, opaleye-0.6.1.0, opaleye-0.6.0.0, opaleye-0.5.4.0,
  opaleye-0.5.3.1, opaleye-0.5.3.0, opaleye-0.5.2.2, opaleye-0.5.2.0,
  opaleye-0.5.1.1, opaleye-0.5.1.0, opaleye-0.5.0.0, opaleye-0.4.2.0,
  opaleye-0.4.1.0, opaleye-0.4.0.0, opaleye-0.3.1.2, opaleye-0.3.1, opaleye-0.3,
  opaleye-0.2, opaleye-0.6.7002.0, opaleye-0.6.7001.0, opaleye-0.6.7000.0,
  opaleye-0.5.2.1, opaleye-0.3.1.1 (has the same characteristics that caused the
  previous version to fail: excluded by constraint '^>=0.7' from example)
  [__1] fail (backjumping, conflict set: example, opaleye)
  After searching the rest of the dependency tree exhaustively, these were the
  goals I've had most trouble fulfilling: opaleye, example
  ```

  There are so many things that are wrong here. Even a sneaky _«to do»_
  remark. If you wonder, in this case the solution is to remove and re-generate
  `cabal.project.freeze`.

  Even the name of the program — it is actually _«cabal-install»_ — is
  incomprehensible, it should be re-branded to Cabal, which is how everyone
  calls it anyway.

* Features are not being introduced.

  There is no reason for two build tools to exist. The killer feature of Stack —
  snapshots — should be supported by Cabal. Possibly Cabal itself should be
  refactored and split so that there are separate tools for packaging, version
  resolution and human interaction — I do not know. But certainly the way things
  are presently is a waste of developer effort and a source of confusion for
  everyone.

### My proposition, in particular.

* Ask all the people that show compassion to the cause of a great Haskell build
  tool to unite and work together on a better Cabal. This includes the
  developers of Stack and everyone that expressed unhappiness with the current
  state of Cabal. These people should be seen as a blessing, not as an obstacle.
* Put in place a clear process for contributing and decision making, so that it
  does not come down to the privileged opinion of one of the core developers.
* Make a model of user experience that Cabal should conform to, and make
  conformance a priority. Surely there are among us people that know a thing or
  two about user experience — call for them to step forward. Every issue that
  stems from misunderstanding, re-assign to the model instead of closing.
* Merge the support of Stackage snapshots into Cabal. Ask the core developers of
  Stack to join the effort. Transition from Stack to Cabal should be one well
  discoverable command that just works.

I realize that this letter is largely an opinion piece. You can also see it as
an _«ideal piece»_. Without an ideal, without a vision, we are stuck with the
present. I do not insist that my vision is the best. But the present reality is
not the best vision either. I propose, foremost, that we work and fight for a
better future.

[1]: https://github.com/commercialhaskell/stackage/issues/4472
[2]: https://github.com/tomjaguarpaw/tilapia/issues?q=is%3Aissue+is%3Aopen+cabal
_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.


--
Alberto.

_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
Reply | Threaded
Open this post in threaded view
|

Re: Do something about Cabal?

Haskell - Haskell-Cafe mailing list
In reply to this post by Bardur Arantsson-2

December 11, 2020 7:50 PM, "Bardur Arantsson" <[hidden email]> wrote:

> On 10/12/2020 22.07, Jack Kelly via Haskell-Cafe wrote:
>
>> [snip]
>
> Absolutely agreed that there is currently to "Right Answer"(TM) wrt.
> Cabal or Stack. They do different things well/badly. Until we get a tool
> that can do everything the schism will probably remain.
>
> (And that's not even talking about issues like technical debt in each of
> the code bases, etc.)

I'm glad my message was taken in the right way.

> My problem here is that Cabal hasn't provided some very useful the
> features that YAML does out of the box, namely the ability to define
> arbitrary snippets of package configuration and to refer to them from
> multiple places. Examples:
>
> If I maintain a cohesive set of 5 packages, I need to duplicate various
> bits and bobs of information in 5 different places:
>
> [snip things that really should be DRY'd up by a modern build tool]

While it does not solve the problem you have in full, common stanzas can at least help you de-duplicate ghc-options settings within a package. https://cabal.readthedocs.io/en/latest/cabal-package.html?#common-stanzas

A possible solution: allow cabal.project to set common entries across multiple packages, and have `cabal sdist` write them into the cabal file that goes into the tarball? This is just me spitballing, so there are probably problems that I haven't considered.

> This is tedious at best and outright wrong
> at worst (inconsistent version bounds).
> In no way am I advocating for YAML specifically.
> (Dhall could work here since you can at least do inclusions and reuse in
> a generic way. Plus it has fully defined semantics plus implementations
> in at least a couple of langauges, Haskell and Scala.)

I see that Oliver has already mentioned dhall-to-cabal . I'm a fan, but I'd be worried about bootstrappability if it became the main language of the main build tool.

>> - Many stack projects do not provide bounds on dependencies
> I posit that at least a *part* of the problem here is tedium for
> maintainers (see above), but while we're at it: I'm not sure manually
> maintaining bounds is at all scalable nor particularly "correct" (for
> lower bounds, esp.) unless one is *super*-vigilant about what bits of a
> dependency are *actually* in use.
>
> FWIW, I do try to do this for my packages, but I'm very confident that
> all of my packages probably have misleading lower bounds.
>
> It seems to me that some automated tooling is needed here, e.g. to try
> building/testing with e.g. all deps at the lower bound, all deps at the
> highest bound, etc.

No doubt. The only way to have a hope of doing this is with a CI matrix. https://github.com/haskell-CI/haskell-ci used to get some of the way there, but Travis CI recently yanked the rug out from under FOSS projects. I believe there is active work to make that repo support other CI systems. (More hands would probably help.)

A possible compromise for bounds: use ^>= bounds, raising the lower bound when you either a) need something from a new version, or b) move to a new major version? If you remain open to metadata revisions that relax the lower bound if needed, that might be OK? Again, spitballing, and I expect some kind soul to point out the flaws in this plan.

Best,

-- Jack
_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.
12