From bryan at haskell.foundation  Fri Nov  1 11:34:26 2024
From: bryan at haskell.foundation (Bryan Richter)
Date: Fri, 1 Nov 2024 13:34:26 +0200
Subject: Your vision for the future of Cabal subsystems
In-Reply-To: <CAKFCL4Ui1bhpr5qrX8qSS4JiVG8isLv9LcR0u+QDrsRKb8CX+g@mail.gmail.com>
References: <CAK-_mHHO89FsrbhRw53mPnHTEVz8wvBRw5-bSgTKdbGLhPF7Pw@mail.gmail.com>
 <CAKFCL4UcNVvA+BL0A9pwF7RRrAHB4herpBfR0WwQeX0Ufj+sTQ@mail.gmail.com>
 <CAPKAvQXmbuRjKGWSfPwz7cYxo=i21pJfTqa=4O7DmUxMsx9DLw@mail.gmail.com>
 <CAKFCL4Ui1bhpr5qrX8qSS4JiVG8isLv9LcR0u+QDrsRKb8CX+g@mail.gmail.com>
Message-ID: <CACUTo6w9bnFD5=irUX7XOLjENqao4zEOG_u-guj24g9BsS60AA@mail.gmail.com>

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 <allbery.b at gmail.com> 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 <a.pelenitsyn at gmail.com>
> 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 <allbery.b at gmail.com>
>> 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 at 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 at haskell.org
>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel
>>>>
>>>
>>>
>>> --
>>> brandon s allbery kf8nh
>>> allbery.b at gmail.com
>>> _______________________________________________
>>> cabal-devel mailing list
>>> cabal-devel at haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel
>>>
>>
>
> --
> brandon s allbery kf8nh
> allbery.b at gmail.com
> _______________________________________________
> cabal-devel mailing list
> cabal-devel at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/cabal-devel/attachments/20241101/0f0debf5/attachment.html>

From sebright2 at proton.me  Tue Nov  5 21:17:54 2024
From: sebright2 at proton.me (sebright2)
Date: Tue, 05 Nov 2024 21:17:54 +0000
Subject: Your vision for the future of Cabal subsystems
Message-ID: <4wvzVmc3EVqzbO4kcu59Cifi8Wifapfd3v9hSF4C3on4Rpl73EL3Q27FuLA6PB_VB60a_jMAbjFyHzeAbDTf45S-S0w8l5jFmcgEV22O_Jw=@proton.me>

Here are my main goals for the dependency solver:

- Finish implementing per-component dependency solving: https://github.com/haskell/cabal/issues/4087
- Improve performance in the case where there are many dependencies, especially setup and build tool dependencies, but not many conflicts. It would solve issues like https://github.com/haskell/cabal/issues/6309 and make freeze files more useful.
- Improve error messages when there is no solution. In simple cases, we might be able to use heuristics (or even an LLM as Artem suggested) to highlight the most important conflicts or suggest solutions. I'd also like the message to focus more on the final conflict set than on the first conflicts encountered, which would help in more complex cases.
- Try to find better solutions or make solutions more stable. The solver could also give suggestions on how to improve the solution, such as how to loosen constraints in order to avoid deprecated versions.
- Improve documentation of the algorithm.

-Kristen

> 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


From mikolaj at well-typed.com  Thu Nov  7 21:41:15 2024
From: mikolaj at well-typed.com (Mikolaj Konarski)
Date: Thu, 7 Nov 2024 22:41:15 +0100
Subject: Is Cabal a core library?
In-Reply-To: <85C612B6-2A5F-4D9C-82CD-F1E2D89EAEAF@gmail.com>
References: <8049CE94-945D-412A-9691-0BDA489691E5@gmail.com>
 <CAHFo2upQVu4xM33yZXwsRry9NuQafqGC6Af0sqhPnTSKM-+k5w@mail.gmail.com>
 <CAHFo2uoJxxN-iRVepENH_sCAS6kTcOuYJn1OBqvS8M2essbyNg@mail.gmail.com>
 <85C612B6-2A5F-4D9C-82CD-F1E2D89EAEAF@gmail.com>
Message-ID: <CAHFo2urO1v6DAaZxsRZ2--HHcv022cLAPwNz2ZjdCXH4YBbm0A@mail.gmail.com>

Hi Andrew,

We discussed this on the list and on today's cabal devs
meeting and we are grateful for the proposal and we don't
only accept it, but we'd like to ask you to consider all
cabal packages (`Cabal`, `Cabal-syntax`, `cabal-install`
and `cabal-install-solver`) as core packages. They don't
really make much sense without each other and while
only two of them are GHC boot packages, if I'm not mistaken,
we posit they are all core packages of the Haskell ecosystem.

Cheers,
Mikolaj

On Thu, Nov 7, 2024 at 12:11 AM Andrew Lelechenko
<andrew.lelechenko at gmail.com> wrote:
>
> Hi Mikolaj,
>
> Just a gentle ping, did you come to a conclusion on this?
> (I’m not on cabal-devel mail list)
>
> Best regards,
> Andrew
>
> > On 30 Oct 2024, at 09:03, Mikolaj Konarski <mikolaj at well-typed.com> wrote:
> >
> > In fact, I'm not sure you are on the cabal-devel list, so I should
> > have added you to CC of this email.
> >
> > ---------- Forwarded message ---------
> > From: Mikolaj Konarski <mikolaj at well-typed.com>
> > Date: Wed, Oct 30, 2024 at 9:59 AM
> > Subject: Fwd: Is Cabal a core library?
> > To: <cabal-devel at haskell.org>
> >
> >
> > Andrew, thank you for your kind offer.
> >
> > Let me forward this to other Cabal developers.
> >
> > Best regards,
> > Mikolaj
> >
> > ---------- Forwarded message ---------
> > From: Andrew Lelechenko <andrew.lelechenko at gmail.com>
> > Date: Wed, Oct 30, 2024 at 1:50 AM
> > Subject: Is Cabal a core library?
> > To: Mikolaj Konarski <mikolaj at well-typed.com>, Hécate <hecate at glitchbra.in>
> >
> >
> > Hi Mikolaj and Hecate,
> >
> > There is a push to consolidate notions of boot (= needed to build GHC)
> > and core (= under CLC aegis) libraries, so that critical parts of
> > Haskell ecosystem are more resilient. How do you feel about
> > designating `Cabal` and `Cabal-syntax` as core packages?
> >
> > While at the moment Cabal has a very healthy team (thanks a ton for
> > your work!), there were moments in Cabal history when things were
> > drastically different. So having an additional safety net, such that
> > CLC is able to provide additional / emergency maintenance, could be
> > helpful in future.
> >
> > Designating a library as a core package does not impose much change on
> > day-to-day operations. CLC does not interfere with daily development
> > of Core Libraries as long as appointed maintainers keep them in an
> > appropriate shape and support healthy communication with contributors.
> > You can find the full policy at
> > https://github.com/haskell/core-libraries-committee?tab=readme-ov-file#core-libraries
> >
> > (Feel free to forward to other Cabal developers)
> >
> > Best regards,
> > Andrew
>

From oleg.grenrus at iki.fi  Fri Nov  8 12:33:46 2024
From: oleg.grenrus at iki.fi (Oleg Grenrus)
Date: Fri, 8 Nov 2024 14:33:46 +0200
Subject: Is Cabal a core library?
In-Reply-To: <CAHFo2urO1v6DAaZxsRZ2--HHcv022cLAPwNz2ZjdCXH4YBbm0A@mail.gmail.com>
References: <8049CE94-945D-412A-9691-0BDA489691E5@gmail.com>
 <CAHFo2upQVu4xM33yZXwsRry9NuQafqGC6Af0sqhPnTSKM-+k5w@mail.gmail.com>
 <CAHFo2uoJxxN-iRVepENH_sCAS6kTcOuYJn1OBqvS8M2essbyNg@mail.gmail.com>
 <85C612B6-2A5F-4D9C-82CD-F1E2D89EAEAF@gmail.com>
 <CAHFo2urO1v6DAaZxsRZ2--HHcv022cLAPwNz2ZjdCXH4YBbm0A@mail.gmail.com>
Message-ID: <1926e048-8dd1-4991-a70d-c8eba9c34710@iki.fi>

I strongly disagree. "Cabal and Cabal-syntax" and cabal-install stuff 
are separate. Would you suggest stack to be a core library too? It 
heavily relies on Cabal/-syntax (and hackage-security).

In my opinion, the development of Cabal-the-library and cabal-install 
should perfectly be in separate repositories. As far as I can tell. The 
only thing holding that down is a kitchen-sink test-suite.

It's not uncommon that people thinking only about cabal-install make 
suboptimal design decisions for Cabal-the-library. It's a library used 
much more than just in cabal-install.

- Oleg

On 7.11.2024 23.41, Mikolaj Konarski wrote:
> Hi Andrew,
>
> We discussed this on the list and on today's cabal devs
> meeting and we are grateful for the proposal and we don't
> only accept it, but we'd like to ask you to consider all
> cabal packages (`Cabal`, `Cabal-syntax`, `cabal-install`
> and `cabal-install-solver`) as core packages. They don't
> really make much sense without each other and while
> only two of them are GHC boot packages, if I'm not mistaken,
> we posit they are all core packages of the Haskell ecosystem.
>
> Cheers,
> Mikolaj
>
> On Thu, Nov 7, 2024 at 12:11 AM Andrew Lelechenko
> <andrew.lelechenko at gmail.com> wrote:
>> Hi Mikolaj,
>>
>> Just a gentle ping, did you come to a conclusion on this?
>> (I’m not on cabal-devel mail list)
>>
>> Best regards,
>> Andrew
>>
>>> On 30 Oct 2024, at 09:03, Mikolaj Konarski <mikolaj at well-typed.com> wrote:
>>>
>>> In fact, I'm not sure you are on the cabal-devel list, so I should
>>> have added you to CC of this email.
>>>
>>> ---------- Forwarded message ---------
>>> From: Mikolaj Konarski <mikolaj at well-typed.com>
>>> Date: Wed, Oct 30, 2024 at 9:59 AM
>>> Subject: Fwd: Is Cabal a core library?
>>> To: <cabal-devel at haskell.org>
>>>
>>>
>>> Andrew, thank you for your kind offer.
>>>
>>> Let me forward this to other Cabal developers.
>>>
>>> Best regards,
>>> Mikolaj
>>>
>>> ---------- Forwarded message ---------
>>> From: Andrew Lelechenko <andrew.lelechenko at gmail.com>
>>> Date: Wed, Oct 30, 2024 at 1:50 AM
>>> Subject: Is Cabal a core library?
>>> To: Mikolaj Konarski <mikolaj at well-typed.com>, Hécate <hecate at glitchbra.in>
>>>
>>>
>>> Hi Mikolaj and Hecate,
>>>
>>> There is a push to consolidate notions of boot (= needed to build GHC)
>>> and core (= under CLC aegis) libraries, so that critical parts of
>>> Haskell ecosystem are more resilient. How do you feel about
>>> designating `Cabal` and `Cabal-syntax` as core packages?
>>>
>>> While at the moment Cabal has a very healthy team (thanks a ton for
>>> your work!), there were moments in Cabal history when things were
>>> drastically different. So having an additional safety net, such that
>>> CLC is able to provide additional / emergency maintenance, could be
>>> helpful in future.
>>>
>>> Designating a library as a core package does not impose much change on
>>> day-to-day operations. CLC does not interfere with daily development
>>> of Core Libraries as long as appointed maintainers keep them in an
>>> appropriate shape and support healthy communication with contributors.
>>> You can find the full policy at
>>> https://github.com/haskell/core-libraries-committee?tab=readme-ov-file#core-libraries
>>>
>>> (Feel free to forward to other Cabal developers)
>>>
>>> Best regards,
>>> Andrew
> _______________________________________________
> cabal-devel mailing list
> cabal-devel at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/cabal-devel