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          | h.goebel@crazy-compilers.com               |
| www.crazy-compilers.com | compilers which you thought are impossible |