Cabal UX discussion

#1

I looked through the cabal issue tracker and assuming you use the same github nick, I found no issues at all submitted by you to cabal-install?

In any case, with cabal, as with all projects, only issues which make some degree of sense to maintainers and which are feasible in the scope of the existing structure and codebase will get through. But in the cabal case, the current batch of maintainers has worked pretty hard to reach out and address many usability issues which are recognized to hit newer users rather than “experts” such as themselves, and there is also new blood amongst maintainers in terms of people with different ux expectations, so ux issues typically get a broad spread of discussion rather than a single firm “yes” or “no”.

3 Likes
Modularizing GHC, do we want an HFTP?
#2

Maybe its changed, but the big one I had in mind was this one:

This one turned out well after a lot of convincing abd is pretty old, so I guess I should stop counting it.

Another is any related to nix integration like:

While ljoking for examples, I saw proof enough of what you say about things being seriously considered by current maintainers here on a large issue.

So happily, I’ll concede it appears you are right and I will resume reporting any Cabal issues I encounter.

4 Likes
#3

On the last topic (nix) it often ends up (as on that ticket) that key people involved in haskell nix work are solicited and weigh in and their comments amount to “we really don’t need anything from cabal here.” The one thing that there has been ongoing work on that is relevant to nix, but much else besides, is ensuring that cabal v2 commands have a genuinely “offline” mode that can restrict them to a much more externally fixed package universe.

2 Likes
#4

@sclv there’s only two things that (in my haskell nix integration) are a bit cumbersome to deal with cabal. These are

  • excessive requirement to pass constraints to prevent cabal from solving. I know the set of packages I want this to be built against with Setup.hs, and there is only one package instance for each package in the package db, however Setup.hs keeps running the solver, unless I pass constraints for each package. Something like: please just use this package-db, and don’t try to solve anything would be a helpful flag to Setup.hs’s interface.
  • plan.json only containing a subset of information. If it would contain the full build plan this would be helpful. (Or a separate cabal solve tool, that takes a GHC description (ideally not interrogate GHC), a cabal.project file, and a hackage index state), and produce the dependency tree.

The reason is as follows: what we use cabal-install to solve for the project. And then use that information to provision a proper package database, which we then use to build the project using the lower level Setup.hs. This approach allows us to trivially support cross compilation.

2 Likes
#5

Am I correct in recalling that someone has moderator powers to split the thread? I too would like to discuss Cabal things, but it’s a bit off topic from this thread :), I suppose I would like to make an actual HFTP at some point if the contributions kicked off by the paper (GSOC and otherwise) go well, so it would be good if it didn’t stray too much :).

Done, thanks @jaror!

I think @angerman’s list is good, but I also want a black-box way for an external tool to provide package sources, so rather than using things like active-repositories source-repository-package I can build the exact index/repository I want with Nix and then feed it to cabal-install. My coworkers and I are very fond of how we can pin inputs for all languages in a uniform way with Nix. The ability to use that in conjunction with package manager solvers (like haskell.nix leverages) is a goldilox best-of-both-worlds we’ve long wanted!

1 Like
#6

Granted :slight_smile:

Note that normal users can post their own reply in a new thread, see: Hello, foundation! - #24 by jaror

3 Likes
#7

Out of curiosity, what information is missing?