Edouard Klein 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.