cabal.project parser ignores the last package if it doesn't end in newline

[srid]

No description provided.

[ParetoOptimalDev]

This seems to happen with a leading newline too:

packages:
  . 

  # some comment
   another-package

[srid]

<rant>
If only the cabal ecosystem had gone with JSON/TOML, like Rust Cargo does, rather than re-inventing their own formats ...
</rant>

[andreasabel]

In a cabal.project file, packages: foo is perfectly valid, but not recognized by a parser that insists that packages: is followed by a newline character:

haskell-flake/nix/haskell-parsers/parser.nix

Line 25 in f16e7ac

key = parsec.string "packages:\n";

Also packages: foo bar is valid syntax, which isn't recognized by a parser that insists on newline characters between package names.

haskell-flake/nix/haskell-parsers/parser.nix

Lines 26 to 28 in f16e7ac

	val =
	parsec.many1
	(parsec.between spaces1 newline path);

In the wild:
https://github.com/tree-sitter/haskell-tree-sitter/blob/387494ab7f4efd9f4d3cdbf8e60ed55bc1f1688a/cabal.project

The official parser is implemented here: https://github.com/haskell/cabal/blob/84acb0e9510c82caae1c1bc4397aafca7f25f83a/cabal-install/src/Distribution/Client/ProjectConfig/Legacy.hs#L1207-L1210
https://github.com/haskell/cabal/blob/84acb0e9510c82caae1c1bc4397aafca7f25f83a/cabal-install/src/Distribution/Client/ProjectConfig/Legacy.hs#L1239-L1273
Yeah, that's a mouthful... agree to the rant. Maybe a tool like https://hackage.haskell.org/package/cabal2json could help (if it was maintained).

[roberth]

Part of the reason to reimplement it in Nix is to avoid "import from derivation", making it so that the flake attributes can be determined without doing any builds. It keeps things like nix build shell completions fast, among other benefits.