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

[aisamanra]

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.

[ezyang]

I think I understand what you are asking for, but just to make sure, can you give an example command line invocation, and what cabal.project.local you would like output?

[aisamanra]

Sure! Straightforwardly enough, an invocation like

$ cabal new-configure --extra-project=/home/user/sample/sample.cabal

would write out a cabal.project.local that includes

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

[ezyang]

OK I specced it out at top. PR welcome.

[acfoltzer]

👍 but for --extra-package rather than --extra-project

[acfoltzer]

@aisamanra: is there a PR for this issue I can reference?

[ezyang]

There's no PR, pr-welcome just means that we think we've specced out this feature sufficiently for someone to come in an implement it.

[aisamanra]

I think @acfoltzer is asking me about a PR because he knows I've already implemented this, and sadly no, there's no PR/commit yet because I got busy with other things and didn't get around to adding proper tests for it, which I will do very soon.

[ezyang]

Well, feel free to PR even prior to tests. (If our test frameworks are so bad that it's stopping you from adding tests, that's a problem and we should fix it.)

[aisamanra]

I was talking to @acfoltzer about this, but I should bring it up here, too: the first pass at implementing this feature just took the paths given to --extra-package= and added them directly to cabal.project.local, but this ends up producing surprising behavior if you're working in some subdirectory of a project: any relative paths are then interpreted as being relative to the project root, and not where you ran new-configure. My instinct is that a user would expect that path to be interpreted relative to the directory where they ran new-configure.

Given that the whole point here is that cabal.project.local is local and ephemeral and shouldn't get checked in to a repo, my intuition is that we should just turn relative paths into absolute paths after interpreting them relative to where new-configure is invoked, and then only add those resulting absolute paths to cabal.project.local. Does this sound like an acceptable approach?

(The alternatives are to attempt to rebuild a different relative path that's relative to the project root instead—which is difficult and error-prone, especially in the presence of symlinks—or to stipulate that the thing I'm describing isn't a problem and that new-configure should always interpret its arguments as relative to the project root—which isn't my present intuition, but I could be wrong!)

[ezyang]

Well, one question is whether or not users expect to move a source dir from one folder to another and have the build products still work. What if you just did curRelativeDir </> userGivenDir? That would get you something actually fairly reasonable in most cases.

[ezyang]

I'm going to veto --extra-package, because it conflicts with an existing config knob extra-packages in cabal.project. I suggest --with-package

[phadej]

I'm not sure why

echo "packages: $location" >> cabal.project.local

isn't enough? packages may be specified many times, and the values are concatenated?

---

What I'm trying to say, making v2-configure to be able to generate all possible stuff one might want to put in cabal.project.local is not scalable. The flags which one can pass to v2-build are OK, as that's the point of v2-configure, to supply them once. But everything else is. IMHO, out of scope of v2-configure.

[hvr]

fwiw, the benefit I could see of a --(with-)packages flag is when it's also supported by cabal v2-build for when you want to control the build directly via CLI w/o the need of writing a project-file; or to temporarily augment the current project config ad-hoc with an additional local package without having to create a cabal.project.local or modify the cabal.project.

[phadej]

I agree, if it’s a `v2-build` flag, then it’s in scope of `v2-configure`.

…

On 26 Apr 2019, at 21.06, Herbert Valerio Riedel ***@***.***> wrote: fwiw, the benefit I could see of a --(with-)packages flag is when it's also supported by cabal v2-build for when you want to control the build directly via CLI w/o the need of writing a project-file; or to temporarily augment the current project config ad-hoc with an additional local package without having to create a cabal.project.local or modify the cabal.project. — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.