Le 10 mai 2019 01:53:59 GMT+02:00, Ivan Vilata i Balaguer <i...@selidor.net> a écrit : >Hi! I've been using Guix on top of Debian for more than 2 years and I >saw >something that spurred a doubt about how Guix manages conflicts. > >So the other day I got the following output from ``guix package -u`` >after a >``guix pull``: > > $ guix package --dry-run -u python-jsonschema > The following package would be upgraded: >python-jsonschema 2.6.0 -> 3.0.1 >/gnu/store/va4hgdfx8zbqzyah7vgqkm25g60p8lf3-python-jsonschema-3.0.1 > >guix package: error: profile contains conflicting entries for >python-attrs >guix package: error: first entry: python-attrs@18.2.0 >/gnu/store/awb7awycpf1crpd1kllvk6qzchd4g7lw-python-attrs-18.2.0 > guix package: error: ... propagated from python-jsonschema@3.0.1 >guix package: error: second entry: python-attrs@18.2.0 >/gnu/store/s77kxps7sybxxdny68xkbcp51ffmiwfl-python-attrs-18.2.0 > guix package: error: ... propagated from python-automat@0.6.0 > guix package: error: ... propagated from python-twisted@17.5.0 > guix package: error: ... propagated from python-txtorcon@19.0.0 > guix package: error: ... propagated from magic-wormhole@0.11.2 >hint: Try upgrading both `python-jsonschema' and `magic-wormhole', or >remove one of them from the profile. > >I understand the error message, and upgrading both packages fixed the >issue >indeed. What I don't get is *why* having two different versions of >``python-attrs`` in the profile is considered an error. My >understanding was >that two different packages in the profile should be able to depend on >different versions of the same library without problems, since they are >referred by its absolute path in the store so they don't conflict. I >understand that I may not directly ``guix install`` two versions of the >same >package (because the may e.g. put the same entry under >``$GUIX_PROFILE/bin``), >but in my case ``python-attrs`` is just a dependency package which >doesn't >show up in ``guix package -I``. > >Can anybody shed some light on the issue? Thanks! > >PS: Yes, I started to write about this in the IRC channel but I pasted >too >many command output lines and got banned. Oops!
Hi, With packages written in C for instance you're right: dependencies are directly embeded into binaries. With python however, we cannot embed store paths by default, so we use propagated-inputs instad of regular inputs. Propagated inputs are installed in the profile along with their dependant, recursively, hence the conflict. With executable packages, we could try and wrap packages to define a PYTHONPATH, so we don't have to use propagated inputs, but that's not possible with libraries.
