Skip to content
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 · 14 comments
Open

Comments

@aisamanra
Copy link
Collaborator

@aisamanra 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
Copy link
Contributor

@ezyang 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
Copy link
Collaborator Author

@aisamanra 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
Copy link
Contributor

@ezyang ezyang commented Jul 21, 2016

OK I specced it out at top. PR welcome.

@acfoltzer
Copy link
Collaborator

@acfoltzer acfoltzer commented Jul 21, 2016

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

@acfoltzer
Copy link
Collaborator

@acfoltzer acfoltzer commented Jul 28, 2016

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

@ezyang
Copy link
Contributor

@ezyang 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
Copy link
Collaborator Author

@aisamanra 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
Copy link
Contributor

@ezyang 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
Copy link
Collaborator Author

@aisamanra 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
Copy link
Contributor

@ezyang 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
Copy link
Contributor

@ezyang 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

@phadej
Copy link
Collaborator

@phadej phadej commented Apr 26, 2019

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
Copy link
Member

@hvr hvr commented Apr 26, 2019

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
Copy link
Collaborator

@phadej phadej commented Apr 27, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
5 participants