A file that defines a Cabal package should be officially called «Cabal Pact».

[kindaro]

problem

It is awkward that there is no officially recognized name for files *.cabal that define a Cabal package. Some other languages call them «manifest». I too was inclined to call them so, for the lack of a better pick. But the word «manifest» is flat, boring, it names a phenomenon that is only short lived.

manifest
3 : a list of passengers or an invoice of cargo for a vehicle (such as a ship or plane)

— The Merriam-Webster dictionary.

solution

We have already taken the word «cabal». With a Cabal, one signs a Pact. It also has a fitting connotation of eternal commitment: if you specify version bounds thoroughly, your package will build now and forever, and if you put it to Hackage, you cannot take it back.

With the Haskell Cabal, one Signs a Pact in Blood.

[malteneuss]

Wouldn't it be more straight-forward to also just call it "manifest" or make ".cabal file" the official term? ^^

[philderbeast]

It is awkward that there is no officially recognized name for files *.cabal that define a Cabal package.

I've been calling them packages.

[malteneuss]

The term "package" is usually the whole bundle of (Haskell) files that you upload to a repository like Hackage. You "define" a package with a file like .cabal, but that file alone is usually not the whole package.

[fgaz]

I think that ship has sailed and ".cabal file" is the most used term now

[andreabedini]

The official term would be "package description". cabal-file is what everybody calls them.

[kindaro]

in short

1. We have no ship. We have Swan, Pike and Crawfish in our Haskell's branding.
2. I celebrate that which makes Haskell different.

in long

All of «package», «package description» and «cabal file» are bland and ambiguous terms. Technically we should agree that a package has a description that is stored in a file that is in some sense related to Cabal, so these names are not altogether wrong. But there are many files that are in some sense related to Cabal — for example, cabal.project is also a Cabal file, — and a package description is no more a file than a tale is a book. We can do better.

As Andrea pointed out, the official name is in misalignment with the common names — this highlights the issue. I say no one is sure how the file in question should be called. The branding is weak. We see evidence of this weakness even in the comments here. Ship has not sailed because there is no ship.

That said, I understand the advantages of bland and ambiguous terms. Weak branding is not going to offend or repel anyone particularly strongly. If we say that Haskell has a stable and pragmatic user base that should be retained rather than expanded, then it is easy to believe that bland and ambiguous terms would serve us better. By this measure, Cabal and Hackage were bad picks as well because of their association with counter-cultures. Perhaps Hackage should have been named «Haskell package repository», Cabal «Haskell package manager», and then we should do well to call a pact a «package manager file». The JavaScript and OCaml communities already go that way with npm and opam. Rust, on the other hand, takes care to define itself through naming, with Rust, Cargo and Manifest working synergically towards the image of robustness and practicality. It seems to have served Rust well — it is a thriving language.

While I acknowledge the danger of picking edgy names like Cabal and Hackage, I think these specific picks were excellent because they associate well with the daring hacker ethos and the promise of secret knowledge that I take to be strengths of Haskell. «Pact» is in line with these post-self-ironic names. We are not really a cabal of hackers, and we know that we are not a cabal of hackers, but at the same time in some sense we are. We are daring hackers in the tame sense of the word and we do have access to special and shared, if not secret, knowledge. This is what makes Haskell different. I find this difference to be worthy of celebration.

Of course, without a written brand strategy and actual field research we cannot know which names are better. It is all up to our common sense. Keeping everything the way it has naturally evolved is the safest if boring bet.

[malteneuss]

I don't have any strong feelings towards either naming schemes. It should just be documented in a section that can easily be found by the informal name as well (i could like to do that as part of #9214).

• If we call it "Pact" we also need a catchy name for cabal.project (Rust elegantly avoids this by reusing Cargo.toml; and there i also ever only heard people calling it "cargo file").
• If we stay with "Package description", maybe it should only be mentioned in a reference chapter where technical rigour and completes is more important. Also what would the name of cabal.project be? "Project description"?

Either way is there some authority or process that can give us a decision?

[liamzee]

Pact, while humorous, might be a bit too "weird" for professional use. Imagine people in the office discussing pacts; you might think they were soon to be victims of overwork.

That said, I want to name projects and subprojects "Sarcasm", "Rainbows", "Ponies", and "Unicorns", so I don't have a position to criticize.

[andreabedini]

As Andrea pointed out, the official name is in misalignment with the common names — this highlights the issue.

Just to be clear. It was not my intention to suport the argument for a new name. Many things have both a official and an informal name.

Looking at other ecosystems. What is package.json called? Why is Cargo.toml not called a waybill?

• lso what would the name of cabal.project be? "Project description"?

It is a project configuration or project file (like the .cabal is a cabal file).

I admit it is not written very prominently in the user guide but it says what it does.

The user guide currently says this:

The full configuration of a project is determined by combining the following sources (later entries override earlier ones, except for appendable options):

1. The user-wide global configuration (default: ~/.config/cabal/config)
2. cabal.project (the project configuration)
3. cabal.project.freeze (the output of cabal freeze)
4. cabal.project.local (the output of cabal configure)

Any call to cabal build will consider cabal.project* files from parent directories when there is none in the current directory.

I appreaciate that @kindaro spended thoughts on this but, to be frank, I think marketing is not one of most pressant problems we have.

 Perhaps Hackage should have been named «Haskell package repository»

¯_(ツ)_/¯