I don't actually see the problem in producing a hash of the API you use.

It is simply the hash of the list of your imports.

Is this overspecific? In the sense that it is more restrictive than it could be?

Yes, but at least you get reproducibility and a permanently working build.

Semantic versioning sounds good in theory and often works in practice, but you are relying on the goodwill and the precision of the library maintainer when both of these qualities are in short supply.

The advantage of using module-level hashes is that you:

* Avoid mistakes due to incorrect semantic versioning

* Get maximum flexibility, as you are exploding the 'package cage' and accessing every file individually

* Avoid a lot of 'false incompatibilities', when for example you would like to access a new version of a module in an upgraded package but you can't upgrade because you depend on another package that declares to be compatible only with the previous version of the package you want to upgrade to even when it's not actually using the new module you are interested in at all.

The inconvenience of hashes is that they are cumbersome to manage by hand, but this can be automated.

In fact, the question is not really semantic versioning vs hash-versioning. Both can be used at the module level as well as to the package level.

The question is if we can simplify the dependency management problem by "going smaller", moving from a bunch of related modules (a package) as a unit of code exchange to a single module.

In principle one could even go smaller, considering every function or data type [1] as an independently sharable entity.

So, what is the optimal 'size' for code sharing: package, module, or entity?

Best,

titto

[1]

This actually make a lot of sense if you are interested in cross-language interoperability, see https://github.com/Quid2/zm for an example.

Il giorno ven 11 dic 2020 alle ore 18:02 Joachim Durchholz <jo@durchholz.org> ha scritto:

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.)
_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.