What to do when udpating a package ?

[Edouard Klein]

Dear Guix Developers,

I have a few beginner questions.
Attached to this email you will find the "reverse-package" graph of
python-prompt-toolkit.

reverse.pdf
Description: Adobe PDF document

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