Am 04.04.2018 um 22:13 schrieb Ricardo
Wurmus:
If this is a "pure" application, I'd install it with*out* propagated
inputs. This might not be easy to determine, though.
It is both. It is often used just as an application, but the procedures
that make up the application are just as often used in an interactive
Python session or as a library.
So I'm afraid, we need to install it with propagated inputs.
Stimulated by your question I rethought whether we might come around
propagated inputs, and I did not find a solution. There must only be
one version of a library in each profile, otherwise we'd get
conflicts. We could provide our own implementation of site.py (or
site-customize.py) to avoid *propagating*, but this would not avoid
the *conflicts* but only hide the cause of the conflicts and make
them hard to find (as we already discusses a year or two ago).
https://lists.gnu.org/archive/html/guix-devel/2018-02/msg00456.html
This is about wrapping (or not) using virtual envs. I don’t really see
how this relates to this problem, but maybe I’m missing something
obvious.
Sorry for the confusion, this link shouldn't have been there. I
had pasted it in since I thought it is related and I'm going to
refer to is, but it is not.
--
Regards
Hartmut Goebel
| Hartmut Goebel | address@hidden |
| www.crazy-compilers.com | compilers which you thought are impossible |