haskell / haskell/cabal

How to programmatically interact with Cabal Store?

Open
#7,238 4 comments 1 reaction 0 assignees View on GitHub
type: user-question
Dominant language
Haskell
Stars
1.7k
Forks
750
Avg merge
4d 3h
Merged PRs (30d)
28

Description

Dear Cabal Team,

- I find myself in very difficult position and create this issue as a question.
- I will try to describe it as simple as possible and provide questions for further clarifications.

## Situation

- Gentoo package maintainers kindly asked me to [relax `fay` boundaries for `aeson` and two more packages](https://github.com/faylang/fay/issues/469).
- After that I was unable to release package on Hackage with `HTTP 400 errors`.
- Thus, I decided to upgrade `fay` to `cabal-install 3.2.0.0`.
- Once all hints from `cabal check` were applied, I tried to update Travis CI pipeline with `haskell-ci` utility.
- It switched installation to `v2-` nix-style builds.
- And it seems that `v2-` approach conflicts with current `fay` implementation.
- `fay` is invoking `ghc-pkg` under the hood to access local packages separately (because `fay-base` conflicts with `base` through ambiguous modules names (`Prelude`, `Data.Maybe`, ...)).
- `v2-build` put package in `$HOME/.cabal/store`.
- `fay-base` has dependent packages. They are also affected.

## Questions

I am wondering, is it possible to access `cabal-install` internals, e.g. `Distribution.Client.Store` for interacting with Cabal Store (without replicating its modules)? This particular situation has many points of failures, thus, I kindly ask you to share the roadmap for cabal store:
- is it going to be stable?
- is it going to fully replace `ghc-pkg` mechanics? (if so, what is the estimated deprecation period?)
- Or maybe integrated with global package database?

## Mitigation way

Since required modules are inside executable component `cabal` of `cabal-install`, I am not sure I could easily depend on them.

```
cabal v2-build all
Resolving dependencies...
cabal: Could not resolve dependencies:
[__0] trying: fay-0.24.1.1 (user goal)
[__1] next goal: cabal-install (dependency of fay)
[__1] rejecting: cabal-install-3.2.0.0 (does not contain library, which is
required by fay)
```
In this way, I have to replicate subset of `cabal-install` as internal library in order to unlock described way. I understand that it could be expensive and produce discrepancy with existing codebase in future.

I spent several hours in bug tracker and have not found similar issue with same questions. If I created duplicate for well-known issue, please refer to it and close this one as duplicate.

Best Regards,
@swamp-agr

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.