{foo,bar} /= {foo, bar}, parse of field 'packages' failed

[philderbeast]

cabal/Cabal/doc/cabal-project.rst

Lines 52 to 59 in 3752c3e

	2. They can specify a glob-style wildcards, which must match one or
	more (a) directories containing a (single) Cabal file, (b) Cabal
	files (extension ``.cabal``), or (c) tarballs which contain Cabal
	packages (extension ``.tar.gz``).
	For example, to match all Cabal files in all
	subdirectories, as well as the Cabal projects in the parent
	directories ``foo`` and ``bar``, use
	``packages: */*.cabal ../{foo,bar}/``

The example given in the docs works. If instead I try ../{foo, bar}/ with a comma and space, this fails with:

cabal: Error parsing project file
/.../cabal.project:3:
Parse of field 'packages' failed.

I get the same error with ../{foo bar}/.

Could we have a better error message here about why the parsing failed or a note in the docs about not using spaces within the curlies please? This is an easy trap to fall into as the section in the docs mentions "package location list (space or comma separated)".

cabal/Cabal/doc/cabal-project.rst

Lines 40 to 41 in 3752c3e

	.. cfg-field:: packages: package location list (space or comma separated)
	:synopsis: Project packages.

I scanned this repo for cabal.project files and could not find a test that exercises the {foo,bar} syntax.

[phadej]

Related: I think that cabal-install should move to use some globbing library (e.g. Glob), and not try to implement it itself (even we would need to implement some recognition ourselves). (and the globbing in Cabal should stay as simple as possible).

[philderbeast]

Glob doesn't support brace expansion, Deewiant/glob#32.

[phadej]

I'm not sure whether cabal-install should either. They are relatively straight-forward to expand.

[philderbeast]

The particular example that lead me to try this was one where I wanted to exclude one package that I build with ghcjs so I tried to list packages and the brace expansion seemed offer me that with less keystrokes.

-- brace expansion syntax
packages: lang-haskell/{clip,cmd,comp,detour-via-sci,detour-via-uom,earth,flare-timing,fsdb,gap,igc,kml,latlng,lookup,mask,route,scribe,siggy-chardust,span,task,tasty-compare,time,track,units,zone}/

-- manually listing each
packages:
    lang-haskell/clip
    lang-haskell/cmd
    lang-haskell/comp
    lang-haskell/detour-via-sci
    lang-haskell/detour-via-uom
    lang-haskell/earth
    lang-haskell/flare-timing
    lang-haskell/fsdb
    lang-haskell/gap
    lang-haskell/igc
    lang-haskell/kml
    lang-haskell/latlng
    lang-haskell/lookup
    lang-haskell/mask
    lang-haskell/route
    lang-haskell/scribe
    lang-haskell/siggy-chardust
    lang-haskell/span
    lang-haskell/task
    lang-haskell/tasty-compare
    lang-haskell/time
    lang-haskell/track
    lang-haskell/units
    lang-haskell/zone

[phadej]

That is subjective, but I find the latter clearer. The fact you cannot arbitrarily insert whitespace into glob patterns make them badly suited for longer stuff.

[philderbeast]

What really would have helped me in this case would be a negative match so I can say build all packages but these, something like:

-- with not
packages: **/*.cabal not(**/appview/*.cabal)

-- with another field
packages: **/*.cabal
excluded-packages: **/appview/*.cabal

[phadej]

Negative match is out of question. I think we should stick to something well defined, e.g. POSIX shell semantics, and if anything rather restrict supported features.

BTW: I think we don't support ** in these globs either. And I'm not sure they make sense too much sense here either. (E.g. there are unpacked packages in dist-newstyle/ occasionally).

Anyway, please don't conflate issues. This is clearly a bug report which we'll fix. Discussion of excluded-packages is a feature request which is different.

[philderbeast]

I did a bit of testing and the ** is accepted but seems to behave the same as *. It doesn't match multiple directory levels.

packages:
   **/siggy-chardust.cabal

> cabal new-build all
When using configuration(s) from /.../cabal.project, the following errors occurred:
The package location glob '**/siggy-chardust.cabal' does not match any files or directories.

packages:
    **/**/siggy-chardust.cabal

> cabal new-build all
Up to date

packages:
    **/siggy-chardust/*.cabal

> cabal new-build all
Up to date

packages:
    */siggy-chardust/*.cabal

> cabal new-build all
Up to date

packages:
    **/siggy-chardust/**.cabal

> cabal new-build all
Up to date

packages:
    **/*.cabal

> cabal new-build all
When using configuration(s) from /.../cabal.project, the following errors occurred:
The package location glob '**/*.cabal' does not match any files or directories.

packages:
    **/siggy-chardust.cabal

> cabal new-build all
When using configuration(s) from /.../cabal.project, the following errors occurred:
The package location glob '**/siggy-chardust.cabal' does not match any files or directories.

[phadej]

The ** works as it works because other star expands to zero piece.

% sh
$ ls
cabal.haskell-ci       cabal.project  cli	   CONTRIBUTORS  dist-newstyle	docs	fixtures	  LICENSE   README.md  src
cabal-install-parsers  CHANGELOG.md   collections  dist		 docker		extras	haskell-ci.cabal  Makefile  Setup.hs   test
$ ls **.cabal
haskell-ci.cabal

[szabi]

-- with not
packages: **/*.cabal not(**/appview/*.cabal)

Bash uses ! as an extended glob syntax. I think one should go with common glob idioms, rather than ad-hoc inventing syntax, like not(...).

[philderbeast]

Please read the not(...) as pseudocode.