[bug#41395] [PATCH 1/2] gnu: python-prompt-toolkit: Update to 3.0.5

[Marius Bakke]

Edouard Klein <address@hidden> writes:

>>>      (synopsis "Interpretable Machine Learning (iML) package")
>>>      (description "Interpretable ML (iML) is a set of data type objects,
>>>  visualizations, and interfaces that can be used by any method designed to
>>> diff --git a/gnu/packages/python-xyz.scm b/gnu/packages/python-xyz.scm
>>> index b8a51570c3..5fd7e274e9 100644
>>> --- a/gnu/packages/python-xyz.scm
>>> +++ b/gnu/packages/python-xyz.scm
>>> @@ -8922,6 +8922,7 @@ interactive computing.")
>>>      (build-system python-build-system)
>>>      (propagated-inputs
>>>       `(("python-ipykernel" ,python-ipykernel)
>>> +       ("python-prompt-toolkit" ,python-prompt-toolkit-2)
>>>         ("python-notebook" ,python-notebook)))
>>>      (native-inputs
>>>       `(("python-certifi" ,python-certifi)
>>> @@ -8950,6 +8951,7 @@ notebooks.")
>>>      (propagated-inputs
>>>       `(("python-ipython" ,python-ipython)
>>>         ("python-traitlets" ,python-traitlets)
>>> +       ("python-prompt-toolkit" ,python-prompt-toolkit-2)
>>>         ("python-widgetsnbextension" ,python-widgetsnbextension)))
>>>      (native-inputs
>>>       `(("python-nose" ,python-nose)
>>> @@ -8980,7 +8982,7 @@ in the data.")
>>>      (propagated-inputs
>>>       `(("python-ipykernel" ,python-ipykernel)
>>>         ("python-jupyter-client" ,python-jupyter-client)
>>> -       ("python-prompt-toolkit" ,python-prompt-toolkit)
>>> +       ("python-prompt-toolkit" ,python-prompt-toolkit-2)
>>>         ("python-pygments" ,python-pygments)))
>>>      (native-inputs
>>>       `(("python-nose" ,python-nose)))
>>> @@ -12049,6 +12051,44 @@ collections of data.")
>>>    (package-with-python2 python-backpack))
>>
>> It would be great to update these packages instead of pinning to the old
>> version.  I won't blame you if you don't feel like embarking on that
>> journey though.
>>
>
> In the new patches I'm about to send, I updated them. Alas even their
> latest versions still require python-prompt-toolkit <=2.1, so I had to
> pin the dependencies. I did it in a cleaner way, though.

Oh too bad that updating did not work.  Terrible that these are so tied
to the version of python-prompt-toolkit.  Can you split those updates
out to separate patches, preceding the prompt-toolkit patch?  Then they
can be reverted and tested individually without having to revert the
whole thing in case there are problems.

>>> +(define-public python-prompt-toolkit-2
>>>    (package
>>>      (name "python-prompt-toolkit")
>>>      (version "2.0.7")
>>> @@ -12077,7 +12117,7 @@ collections of data.")
>>>         ("python-pygments" ,python-pygments)))
>>>      (native-inputs
>>>       `(("python-pytest" ,python-pytest)))
>>> -    (home-page "https://github.com/jonathanslenders/python-prompt-toolkit";)
>>> +    (home-page "https://github.com/prompt-toolkit/python-prompt-toolkit";)
>>>      (synopsis "Library for building command line interfaces in Python")
>>>      (description
>>>       "Prompt-Toolkit is a library for building interactive command line
>>> @@ -12104,6 +12144,10 @@ characters, mouse support, and auto suggestions.")
>>>  (define-public python2-prompt-toolkit-1
>>>    (package-with-python2 python-prompt-toolkit-1))
>>>  
>>> +(define-public prompt-toolkit-2-instead-of-prompt-toolkit
>>> +  (package-input-rewriting/spec
>>> +   `(("python-prompt-toolkit" . ,(const python-prompt-toolkit-2)))))
>>
>> Is this actually necessary?  Just changing the inputs as you did above
>> should be sufficient I think.
>
> If one dependency is OK with python-prompt-toolkit in version 3, but a
> package has an implicit dependency on python-prompt-toolkit in version
> 2, then we either have to pin them all to version 2, and the OK
> dependency does not get to envoy the update, or we have to resort to this.
>
> I did it because python-ipython (19 dependents) is OK with
> the update, and I did not want to pin it (and all its dependents) to 
> python-prompt-toolkit-2.
>
> This is my first time making such an involved update, so I'm open to
> suggestions as to alternative ways of doing this.

Oh I see, makes sense.  The new patch is much clearer.  I will send a
separate reply with further comments.

signature.asc
Description: PGP signature