As I mentioned in the call, I'd like the Cabal part of the error message index to thrive (that is, to be the opposite of what it is now). Hécate says Zuri/Muni-hacks will take care of that --- awesome! Hope this happens in my lifetime! I want cabal-install to be more like package manager in Julia where, when I say import Blah and Blah isn't available locally, it tells me: Blah is not installed but we can do it. Proceed? [Y/n] As per later discussions, it'd be interesting to see how the solver could be friendlier to the users. E.g. if we had a little LLM inside cabal (or interfaced with cabal) that could talk through the grievances that user has, and come up with suggestions like adding a constraint or upgrading GHC or something. -- Best, Artem On Thu, Oct 31, 2024 at 1:21 PM Brandon Allbery wrote:

Just to sort-of get the ball rolling:

I don't actually have a lot of a stake in Cabal or cabal-install myself; I mostly work on meta stuff (nursemaiding GHA, maintaining and enhancing workflows and Mergify config, etc.). But there's a similarly "meta" vision I have: better interaction with the real stakeholders, to wit, the users. What are *their* wishes and needs?

On Thu, Oct 31, 2024 at 1:04 PM Theophile Hécate Choutri via cabal-devel < cabal-devel@haskell.org> wrote:

...

Hi everyone,

I'd like to ask the people who have been working, are involved or are dependent on any subsystem of the Cabal project to take some time and think about what they would like to see for the future. More directly, I would like to ask you to dream about the future. Don't concern yourself with implementation, energy or resources, but rather about the direction, and the shape of the subsystems that you have a stake in. Things like the solver, the UX of such and such sub-command, performance of a certain use-case, targeting a certain demographic, a change in how we get feedback from end-users…

This will help us with coming up with a product vision that will serve as a backbone for the immediate and near-future development of cabal. I understand most of us do this in our free time, but that does not make us illegitimate to wish for better things, especially when we are involved in the long run.

See you all on Matrix and during our bi-monthly meeting.

Cheers, Hécate _______________________________________________ cabal-devel mailing list cabal-devel@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel

-- brandon s allbery kf8nh allbery.b@gmail.com _______________________________________________ cabal-devel mailing list cabal-devel@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel

There are two distinct user groups that need different tools: app developers and library developers. Note 1: As an industry programmer, I have noticed that people tend to start out as app developers, and only progress to being a library developer after some experience and career advancement. Academic programmers, on the other hand, seem to start out as library developers. App developers need freeze files. Library developers need dependency version bounds. App developers don't even interact with cabal directly. (They interact with their IDE/editor, which interacts with HLS, ...) Library developers design specifically around Cabal's interface. Libraries and apps have different publishing needs. (I've never thought of Hackage/Cabal as a good system for distributing binaries.) My vision would be that these two groups are more explicitly targeted. Note 2: In the present, I consider stack a better tool for app development: it's easy for newcomers, focused on freeze files, and hides or downplays the complicated ways library versions can interact. -Bryan On Thu, 31 Oct 2024 at 20:03, Brandon Allbery wrote:

Worth noting on that last is that Phil attempted to improve that situation in https://github.com/haskell/cabal/pull/9578, but apparently it's not working for some reason (there was a discussion of this recently but I'm not finding it on a quick scan of PRs).

On Thu, Oct 31, 2024 at 1:34 PM Artem Pelenitsyn wrote:

...

As I mentioned in the call, I'd like the Cabal part of the error message index to thrive (that is, to be the opposite of what it is now). Hécate says Zuri/Muni-hacks will take care of that --- awesome! Hope this happens in my lifetime!

I want cabal-install to be more like package manager in Julia where, when I say import Blah and Blah isn't available locally, it tells me: Blah is not installed but we can do it. Proceed? [Y/n]

As per later discussions, it'd be interesting to see how the solver could be friendlier to the users. E.g. if we had a little LLM inside cabal (or interfaced with cabal) that could talk through the grievances that user has, and come up with suggestions like adding a constraint or upgrading GHC or something.

-- Best, Artem

On Thu, Oct 31, 2024 at 1:21 PM Brandon Allbery wrote:

...

Just to sort-of get the ball rolling:

I don't actually have a lot of a stake in Cabal or cabal-install myself; I mostly work on meta stuff (nursemaiding GHA, maintaining and enhancing workflows and Mergify config, etc.). But there's a similarly "meta" vision I have: better interaction with the real stakeholders, to wit, the users. What are *their* wishes and needs?

On Thu, Oct 31, 2024 at 1:04 PM Theophile Hécate Choutri via cabal-devel wrote:

...

Hi everyone,

I'd like to ask the people who have been working, are involved or are dependent on any subsystem of the Cabal project to take some time and think about what they would like to see for the future. More directly, I would like to ask you to dream about the future. Don't concern yourself with implementation, energy or resources, but rather about the direction, and the shape of the subsystems that you have a stake in. Things like the solver, the UX of such and such sub-command, performance of a certain use-case, targeting a certain demographic, a change in how we get feedback from end-users…

This will help us with coming up with a product vision that will serve as a backbone for the immediate and near-future development of cabal. I understand most of us do this in our free time, but that does not make us illegitimate to wish for better things, especially when we are involved in the long run.

See you all on Matrix and during our bi-monthly meeting.

Cheers, Hécate _______________________________________________ cabal-devel mailing list cabal-devel@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel

-- brandon s allbery kf8nh allbery.b@gmail.com _______________________________________________ cabal-devel mailing list cabal-devel@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel

-- brandon s allbery kf8nh allbery.b@gmail.com _______________________________________________ cabal-devel mailing list cabal-devel@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel