Project config #3226
Project config #3226
Conversation
Getters and setters really need to match up. Detected by parse/print round trip QC tests.
withRepoContext keeps its current type (using GlobalFlags). Added withRepoContext' that takes all the args seprately. Better name suggestions welcome.
The existing approach has been to parse top level fields and then separately parse each top level section, and similarly for pretty printing. A better approach is to follow the pattern for fields and have a section description. Then we just parse or print fields+sections in one call. And as a bonus, secitons can have subsections (and could even do so recursively). This patch just adds the new functionality. No existing config parsing is switched over.
This describes in one place the layout of the new dist dir, as used by the nix-local-build branch. Also a similar approach to describing the layout of the user-wide cabal directory. The idea is that this centralises the description and makes it easier to change and handle systematically (e.g. we have problems currently with some user-wide files not being reolocatable).
One for testing if globs are trivial, as in they're constant strings without the possibility of matching more than one thing. This can help with making better error messages. Another util for matching file globs in the rebuild monad, and automatically monitoring the glob.
We want to reuse the FlagAssignment printer/parser for the config files.
This defines the new cabal.project files and introduces the notion of a project root (and the logic for finding it). Also has support for implicit projects when no cabal.project file is defined. Supports both reading and writing project files or fragments. The printing & parsing round trips correctly. QC tests to follow. This is a key part of the new nix-local-build branch approach, based around projects with clear configuration state held in a project file (or extra files). This has support for file and dirs as packages within a project, including by glob. It supports both globs that much match a target, and optional globs that are allowed to match nothing. It has partial support for local tarball, remote http tarball and remote source repo packages.
Two kinds of round-trip test: * type conversion ProjectConfig -> LegcyProjectConfig and back * ProjectConfig -> print -> parse The latter goes out to the config file format and back. These tests uncovered a number of issues in our general config code.
|
Reviewing note: github shows the patches in the wrong order. It's showing them in date authoring order rather than repository addition order. |
|
Nice! |
|
Phew! Tests pass. |
|
@23Skidoo FYI, I can follow this up pretty soon with project planning and building. Indeed I'll probably make a parallel PR for those building on this one. One issue I'm aware of in this PR is that the file globbing stuff needs a bit of cleaning up. It should be consolidated into the one module rather than spread around. Also, it has some syntactic limitations currently like it cannot match absolute paths nor trailing '/' dir slashes. |
I think the existing syntax is not completely adequate for this, because we'll want to allow specifying the exact revision (actually, we'll want to force people to do it if the tag is not specified). Can be fixed later of course, since this part is not yet finished. |
|
LGTM modulo minor comments. |
I was thinking about this. It looks like the tag field can double up as the revision for git. The original syntax for the "this" kind was of course always intended to specify an exact state of the repo, used to reproduce "this" release. We called the field tag rather than revision because at the time most other source control systems encouraged tagging to identify reusable repo states, especially for releases. But it's morally much the same thing and in git a tag is just a revision with a name. I think if you do specify a revision hash in the tag field then our current git code will check it out successfully. That said, perhaps it's worth just aliasing "revision" to the existing "tag" field. |
Yes, it will run
+1. |
|
Fyi, the tern "revision" is non-idiomatic in the context of Git and would therefore be very confusing IMHO. Idiomatically, you rather refer to "commit-ish" identifiers or sometimes "tree-ish" identifiers depending on what kind of reference you need (unless you need a more specific reference such as a "tag"). See also https://www.kernel.org/pub/software/scm/git/docs/#_identifier_terminology |
However, this won't work in the case of Subversion, in which tags are separate from revisions. To check out a tag, you do |
Stack uses "commit" instead of "revision". |
|
Well, "commit" would be more appropriate (but still inaccurate!), even better would be "committish" if we went for VCS-specialised terms (which IMHO we should, as Git's language for object reference is quite rich -- or some may say over-engineered; terms appropriate for Git don't work well for Svn or Darcs, and vice-versa) |
|
If they're genuinely different concepts for some vcss and just aliases in others, I see no problem adding an extra field to the .cabal file syntax too. The interpretation would, as it does now, depend on the vcs type. We'd then inherit that in the cabal.project files too. |
|
I don't think we'll need "commit-ish" if we'll have both "commit"/"revision" and "tag". We can even validate the "commit" field to make sure that it looks like a SHA-1 hash (in the case of Git). |
|
@23Skidoo So I suggest the As for the commit vs tag, changing this in the Cabal lib at this stage before a release is not realistic, so probably what we should do is add the commit thing locally to cabal-install in the 1.24 branch, and do it in Cabal lib in master and have cabal-install share the one from Cabal lib. So good to merge now? |
|
AppVeyor build failure looks spurious. |
|
Yes, let's merge. |
|
Also cherry-picked into |
Supersedes PR #3156. Significant changes since then:
Split huge
ProjectConfigmodule into three as suggested by @23SkidooProper QC tests: can round trip from
ProjectConfigtype out to a config file and back. Doing this detected lots of plumbing problems which are all now fixed.Several field parsers have to be implemented locally rather than using generic infrastructure. This is directly related to the above point, we need to do that to round trip correctly.
Specifying packages in projects is greatly extended. Previously only one field for globs which could only match
.cabalfiles and the globs were all allowed to match nothing. Matching nothing is useful in one major use case, allowing optional local or "vendor" unpacked deps, so one can just unpack and start using those local deps without any extra explict config however matching nothing is not ok for many other normal use cases. So we now split that into two fieldspackagesandoptional-packages. Only the latter can be globs that are allowed to match nothing.We can now specify packages in the project as:
.cabalfilesOnly the first two have full support. For the rest the syntax is supported but there's not yet support for downloading and unpacking them.