haskell / haskell/cabal

Add flag to `new-configure` for adding extra `packages` to `cabal.project.local`

Open
#3,585 14 comments 2 reactions 0 assignees View on GitHub
attention: pr-welcome cabal-install: v2-build system type: enhancement
Dominant language
Haskell
Stars
1.7k
Forks
750
Avg merge
4d 3h
Merged PRs (30d)
28

Description

**Summary by @ezyang.** An invocation like

```
$ cabal new-configure --with-package=/home/user/sample/sample.cabal
```

should write out a `cabal.project.local` that includes

```
packages: /home/user/sample/sample.cabal
```

The new flag would probably live in `ConfigExFlags` (`Distribution.Client.Setup`). The top-level function which converts command line flags to project config is `commandLineFlagsToProjectConfig` in `Distribution.Client.ProjectConfig.Legacy`. The `packages` field in `cabal.project` is the `projectPackages` field; you would add it as another field setter to the `mempty` in `commandLineFlagsToProjectConfig`.

Don't forget to add a test to `integration-tests` or `integration-tests2`.

**What you will learn.** How the configuration logic for Nix-style local builds (new-build) works, and in particular how the `new-configure` command is implemented.

---

We can already include a `packages` field in both `cabal.project` and in `cabal.project.local`, and `cabal new-build` will consult and use both. What I'd like—and AFAICT doesn't currently exist—is the ability to pass a flag to `cabal new-configure` (maybe something like `cabal new-configure --extra-project=path-or-url-of-cabal-project`) that will add the specified project locations (either local paths or, as per #2189, VCS urls) to the generated `cabal.project.local` file.

This is useful for a few reasons. One use-case is when you depend on a library that's not part of the same project, is available on a local filesystem, and won't necessarily be in the same absolute or relative location on every developer's machine. Another use-case is when you want to locally override an existing dependency to specify a WIP version of that dependency either on the local filesystem or in a VCS. In both these cases, the location of the dependency—being a local detail—would belong in `cabal.project.local` instead of in `cabal.project`.

The functionality to make this work is mostly already in place, except that `cabal.project.local` is usually generated by `cabal new-configure` and there's no way to tell it to add a project except by hand-editing the generated file.

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.