Re: Package API compatibility and guix package variable names

[Danny Milosavljevic <dannym@scratchpost.org>]

Hi Andreas,

On Wed, 27 Jul 2016 18:19:18 +0200
Andreas Enge <andreas@enge.fr> wrote:

>It is our common practice to not re-encode the version into the name: Usually the unnumbered name simply stands for the latest version

That's unfortunate. I can live with it - but there is a reason the API major versions are usually encoded there. Otherwise it's not possible to ever make a clean API break and be safe with it.

Just to make sure: I'm not saying the API major number should absolutely be part of the name, I'm saying there should be version bounds for all the inputs of packages.

> In this way, updating dependencies becomes easier: Most of the time, a later version of a dependency will work. 

Then there would have been no reason to update the API major number in the first place. Of course I can think of scenarios where it would work regardless - for example if the package used only a subset of the entire functionality, it could be that this subset is still compatible.

Python 3 is an example - few Python 2 programs will work on Python 3 without changes - so it makes no sense to "autoupdate" a Python 2 package to a Python 3 interpreter in isolation. Of course, if you are lucky, you can find some subset where it happens to work by accident.

When Python 4 is released, a similar argument can be made.

>To follow your suggestion, we would ultimately add the soname of libraries to package names, 

Only the part that is the API (in)compatibility version number - but yes.

> and then whenever some package is updated, all packages depending on it would need to have
> their inputs rewritten. 

Hopefully after checking whether the new API actually still does the right thing for it...

Thanks, good to know the common practice.