I am updating it from version 2.0.7 to version 3.0.5 because python-questionary (which I'm trying to add to guix) depends on version 3. After writing the new package definition for version 3.0.5, I tried building the packages listed by ./pre-inst-env guix refresh --list-dependent python-prompt-toolkit which if I understand correctly are the leafs of the attached DAG. This is where I ran into different problems. Here are the questions I have: - Some packages would not build, for reasons unrelated to the update of python-prompt-toolkit. Namely: - fdroidserver@1.1.1 will not build because of a failure of python-apache-libcloud@2.4.0 - python-matplotlib-documentation@3.1.2 and python-ipython-documentation@7.9.0 will not build because of a failure of texlive-union-51265 - python-rpy2@3.0.4-1.19868a8 would not build All those failure also happen on origin/master on my machine, and are therefore unrelated to the changes I made. --> Is any failure to build expected on origin/master ? --> If so, where can I check the official build success/fail status of a package ? --> If not, how can I check that my master version of guix is correct and is building everything it should build ? --> In any case, how can I check that my change does not negatively affect these packages ? - Some of the failing-in-master packages do not depend directly on python-prompt toolkit, but they depend on a package that depends on etc. e.g. fdroidserver@1.1.1 depends on python-androguard@3.2.1 which depends on python-ipython@7.9.0. --> fdroidserver@1.1.1 fails to build for reasons unrelated to python-prompt-toolkit, but both python-androguard@3.2.1 and python-ipython@7.9.0. both build with the new version of python-prompt-toolkit. Would I be correct in assuming that frdoidserver would build with the new version ? I assume not, but I would like to be sure - python-iml@0.6.2 does not build with prompt-toolkit in version 3 (the version is explicitly stated as >=2.0 and <2.1 in the Python files), but when I add prompt-toolkit-2 to its propagated-inputs, it does. Given that python-ipython has prompt-toolkit (implicitly in version 3) installed in its propagated inputs, this means that any environment with python-iml will have prompt-toolkit in both its version 2 and 3 installed at the same time. I feel uneasy about this. --> Is this a problem ? --> Should I just trust that if it builds, then everything is allright ? - Same question on a larger scale with r-irkernel@1.1: - it depends on python-jupyter-console (failing) which depends on python-prompt-toolkit. If I pin python-jupyter-console's dependency on python-prompt-toolkit to version 2, python-jupyter-console builds. The next dependency to fail is then python-widgetsnbextension@3.4.2, whose Python files explicitly requires 2.0 <= python-prompt-toolkit <2.1, but whose guix package does not (it relies on python-prompt-toolkit being a propagated input of a propagated input of a propagated etc.). Same for python-ipywidgets@5.2.2. Those packages build when I explicitly add python-prompt-toolkit-2 as a propagated input. Now I feel uneasy about two things: --> Is the concurrent presence in the environment of python-prompt-toolkit both in version 2 and 3 a problem ? --> Is the fact that the graph is now much more connected (2 extra edges) a problem ? --> Is there a way to check the graph to make the edges as sparse as possible (i.e. remove as many edges as possible without changing the reachability) ? Would this be something we want ? According to me it would because it would make the packages definitions shorter and the computations on the graph faster, but I'm not sure. I'm sorry if this is addressed in the documentation, I did not find the relevant parts. guix graph is awesome, it makes working with the dependencies much more intuitive. This email is a mess to anyone not looking at the graph at the same time, but I hope is quite understandable to somebody following along on the graph at the same time. Last question: --> Should I also check the build status of the packages for which python-prompt-toolkit or its dependents are native-inputs ? Why, why not ? Thanks in advance, Cheers, Edouard