Re: Package API compatibility and guix package variable names

[Danny Milosavljevic]

Hi Andreas,

On Wed, 27 Jul 2016 18:19:18 +0200
Andreas Enge <address@hidden> 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.