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