[Haskell-cafe] Do something about Cabal?

[Joachim Durchholz]

Am 11.12.20 um 13:48 schrieb Pasqualino "Titto" Assini:
> I always wondered: do we need a package management system at all?

The main reason package management became a thing is indirect dependencies.

Without package management: Pick up a dependency, manually hunt down 
everything that it depends on, then get the dependencies' dependencies, 
and you never know how many are there to come.
Lather, rinse, repeat with every update. Sometimes you'll need a 
completely new set of indirect dependencies after an update.

With package management, you specify the package you need and the 
package manager will do the rest.
It should also tell you what it pulled in.
If it's worth anything, you can tell it to use different dependencies; 
it's not a silver bullet that will solve your dependency 
incompatibilities for you, but it will give you a reasonable first 
approximation.

> What about a system where every source file is automatically annotated 
> with a unique hash and all the required LANGUAGE extensions.

Hashes are... difficult.

What you really want is a hash of the API you're using, possibly 
including nonfunctional properties. Problem is that it's really hard to 
even define the section of the API that you need - probably an unsolved 
problem, actually.

That's why people find semantic versioning so important.
Usually, you have some global namespace where legal entities reside 
(Java did something that turned out to be pretty smart: domain names are 
per-entity anyway), with each entity assigning module names within their 
namespace.
E.g. the owner of com.company manages com.company.module1, 
com.company.module2, etc.
A module is identified by (sub)domain name and version number, throw in 
some recommendations about how to apply semantic versioning, and people 
will stop using those modules that don't have a good versioning policy 
anyway... and you're done.

It's not perfect, but it works.

(Hashes are overspecific, and they don't help with the relationship 
between version 1.2 and 1.2.2 of a module.)

(Disclaimer: This is from the perspective of the Java ecosystem, 
slightly generalized. Semantic versioning may be less of an issue for 
functional languages than it has been and will be for imperative ones, 
so I don't expect this to carry over 1:1.)