Re: What to do when udpating a package ?

[Edouard Klein <edk@beaver-labs.com>]

Hi Julien,

Thank you for your answer.

Julien Lepiller writes:

> Le 15 mai 2020 03:20:06 GMT-04:00, Edouard Klein <edk@beaver-labs.com> a écrit :
>>Dear Guix Developers,
>>
>>I have a few beginner questions.
>>Attached to this email you will find the "reverse-package" graph of
>>python-prompt-toolkit.
>
> Hi,
>
> In general, some packages on master may fail to build. We try to fix these, but it's not always easy.
>
> When updating a package, you should make sure that its dependents all
> build or did not build before your changes. Fix those who now fail to
> build.

OK, got it. I'll avoid touching those that fail to build on the build farm.

>
> I don't think having both versions is a good thing because it will create conflicts when installing (have you tried to install a package that propagates both to a profile?). It would be ok if they had no file in common but I doubt it is the case. For any package that requires version 2, make sure its dependencies only use version 2, or update the package if the newer version can support version 3. It's not always easy to find the right order of upgrades, as you should make sure nothing is broken in between patches.
>
I did not try to install them, and you were correct, here is what I get
when I try to install python-iml:

guix install: error: profile contains conflicting entries for python-prompt-toolkit
guix install: error:   first entry: python-prompt-toolkit@3.0.5 /gnu/store/80lzvbzvfp4226ic7czhch4p0mlsdwlv-python-prompt-toolkit-3.0.5
guix install: error:    ... propagated from python-ipython@7.9.0
guix install: error:    ... propagated from python-iml@0.6.2
guix install: error:   second entry: python-prompt-toolkit@2.0.7 /gnu/store/0k7a0yp3b2sqqj8jhl7vp3cabb0x2mwd-python-prompt-toolkit-2.0.7
guix install: error:    ... propagated from python-iml@0.6.2
hint: You cannot have two different versions or variants of `python-iml' in the same profile.

The problem is that python-iml depends on both python-ipython (which
accepts python-prompt-toolkit 3) and python-prompt-toolkit-2. Looking at
the github repo, the last update was in 2018, I don't think we'll see an
update soon.

I could pin python-ipython to python-prompt-toolkit-2, but that would
just delay the problem and put it on somebody else's lap to let
python-ipython move to python-prompt-toolkit 3.

As I was typing a question I ctrl-Fed for 'variants' in the doc and
ended up learning about package-input-rewriting. I will try to make
python-iml depend on python-ipython, but with the prompt-toolkit input
replaced with its version 2 on the fly. I think it makes sense. Is it the correct
way to do what needs to be done ?

> Relying on propagated inputs to provide a dependency is going to
> simplify the graphs, but not the work of other maintainers who will
> have to investigate how the dependency is provided, so I don't think
> it's a good idea.

I understood your sentence as saying that relying on propagated inputs
of propagated inputs is not a good idea and that dependencies are better
explicitly stated in the guix package. Is that correct ?


>
> You should rebuild every dependent, even those who only depend on the
> package for native-inputs, since there can be an error an any point
> (though less likely).

OK, I'll try that next when I'll have gotten python-iml to build.

>
> I hope I answered your questions. Your message was split into two
> multipart sections and my client wasn't able to cite the interesting
> part, which makes it hard for me to check what your questions were
> while typing my answer.

You have indeed answered a lot of them, thank you very much :) Sorry
about the multipart stuff, I don't know how to configure my client
(mu4e) not to do that. I'll look into it.

Cheers,

Edouard.