Consistency in cabal files #196

myroslambda · 2021-11-26T08:34:44Z

The cabal files do not have consistent syntax. For example, some times, a space is left before :. Sometimes it is not. Some keywords are all lowercase, some mix cases.

Would you accept a PR that standardizes the syntax of all cabal files?

The text was updated successfully, but these errors were encountered:

ivanperez-keera · 2021-11-26T23:49:48Z

Potentially.

It's not enough that they be consistent. They'd have to conform to some written rules, otherwise it becomes a situation where the most repeated formatting "mistakes" could win.

We currently don't have any written rules, but I'd be open to having something. I don't have a ton of time, but I can take a quick look if someone wants to give it a shot.

But personally, it bugs me more that we don't have a consistent style for Haskell files.

myroslambda · 2021-11-29T09:48:33Z

KS' current cabal style guide and Haskell style guide are available online.

The license is CC-By-NC-SA, in case anyone needs to adapt them.

Would that be good starting points?

ivanperez-keera · 2021-12-01T04:41:15Z

Thanks. I probably won't have time very soon to take a deep look but I'll respond as soon as I can.

ivanperez-keera · 2021-12-03T03:19:40Z

I'm really not going to have time to review this soon. Anything that can be done to shorten the amount of time necessary to make a decision would be highly appreciated (e.g., divide this in two tasks; select fewer rules, more direct rules, etc.).

Include missing license in Cabal file.

. Sort initial package fields in the following order: name version author maintainer homepage license license-file category synopsis description Note: - Copyright is missing. Change description value to start in next line.

…- 3). Refs #196. Move source repository declaration to head of file, following style guide.

Fields within library, executable, test suites and benchmarks are listed in the following order: - type, if applicable - main-is, if applicable - exposed-modules, if applicable - other-modules, if applicable - build-depends - default-language - hs-source-dirs - compiler options - flag-dependent configuration

sort modules in exposed-modules in library in alphabetical order.

. Packages listed in fields such as build-depends should always be listed one package per line, with the comma that separates items being the character in the line. This change also lists packages in alphabetical order.

Fields within library, executable, test suites and benchmarks are listed in the following order: - type, if applicable - main-is, if applicable - exposed-modules, if applicable - other-modules, if applicable - build-depends - default-language - hs-source-dirs - compiler options - flag-dependent configuration

…196. Fields within library, executable, test suites and benchmarks are listed in the following order: - type, if applicable - main-is, if applicable - exposed-modules, if applicable - other-modules, if applicable - build-depends - default-language - hs-source-dirs - compiler options - flag-dependent configuration

Modules listed in fields such as exposed-modules and other-modules should always be listed in alphabetical order, one module per line.

….7.3). Refs #196. Packages listed in fields such as build-depends should always be listed one package per line, with the comma that separates items being the first character in the line.

. Packages listed in fields such as build-depends should always be listed one package per line, with the comma that separates items being the first character in the line.

…196. A Cabal file consists of, in order: 1. License or copyright information 2. Cabal version declaration and build type declaration 3. Package metadata 4. Source repository declarations, if present 5. Flag declarations, if present 6. Libraries, if present 7. Executables, if present 8. Tests, if present 9. Benchmarks, if present

A Cabal file consists of, in order: 1. License or copyright information 2. Cabal version declaration and build type declaration 3. Package metadata 4. Source repository declarations, if present 5. Flag declarations, if present 6. Libraries, if present 7. Executables, if present 8. Tests, if present 9. Benchmarks, if present

Fields within library, executable, test suites and benchmarks are listed in the following order: - type, if applicable - main-is, if applicable - exposed-modules, if applicable - other-modules, if applicable - build-depends - default-language - hs-source-dirs - compiler options - flag-dependent configuration

….7.2). Refs #196. Modules listed in fields such as exposed-modules and other-modules should always be listed in alphabetical order, one module per line.

Packages listed in fields such as build-depends should always be listed one package per line, with the comma that separates items being the character in the line.

For all settings in libraries, executables, tests and benchmarks, their values should be set in a new line.

A single blank line always appears: 1. Between consecutive sections. 2. Between consecutive entries of a section.

A single ASCII space also appears in the following places: - On both sides of any binary or ternary operator.

Horizontal alignment is required in the following: - For the values of the fields denoting the Cabal version, the build type, and other package metadata, except when the values of those fields are given in a separate line.

Horizontal alignment is strongly encouraged in the following: - For lower and upper version bounds of libraries listed together within build-depends fields.

Other package metadata should follow the package name in the following order. - name - version - author - maintainer - homepage - license - license-file - copyright - category - synopsis - description - data-files, if applicable