New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
aisamanra opened this Issue Jul 21, 2016 · 11 comments

Comments

Projects
None yet
3 participants
@aisamanra
Collaborator

aisamanra commented Jul 21, 2016

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

This comment has been minimized.

Contributor

ezyang commented Jul 21, 2016

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

This comment has been minimized.

Collaborator

aisamanra commented Jul 21, 2016

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

This comment has been minimized.

Contributor

ezyang commented Jul 21, 2016

OK I specced it out at top. PR welcome.

@acfoltzer

This comment has been minimized.

Collaborator

acfoltzer commented Jul 21, 2016

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

@acfoltzer

This comment has been minimized.

Collaborator

acfoltzer commented Jul 28, 2016

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

@ezyang

This comment has been minimized.

Contributor

ezyang commented Jul 28, 2016

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

This comment has been minimized.

Collaborator

aisamanra commented Jul 28, 2016

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

This comment has been minimized.

Contributor

ezyang commented Jul 28, 2016

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

This comment has been minimized.

Collaborator

aisamanra commented Aug 2, 2016

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

This comment has been minimized.

Contributor

ezyang commented Aug 2, 2016

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

This comment has been minimized.

Contributor

ezyang commented Aug 30, 2016

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment