Add flag to `new-configure` for adding extra `packages` to `cabal.project.local`
- 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
Assessment
This issue has not been assessed yet.