Hi Hartmut,
> Für welche Fälle wird PYTHONPATH eigentlich gesetzt - sprich für welche
> Fälle brauchen wir eine Lösung?
>
> 1. guix environment --ad-hoc python: NEIN, da das environment
> "komplett" ist
We set PYTHONPATH here, because the search path is attached to the
“python” package. I
On Sat, Jul 06, 2019 at 12:45:19PM +0200, Hartmut Goebel wrote:
> Hallo Ricardo,
>
> ich wollte meine Fäden zu diesem Thema wieder aufnehmen und meine
> bisherigen Erkenntnisse so zusammenstellen, dass jmd. anderes auch etwas
> damit anfangen kann (und ich kein Flaschenhals bin).
>
> Da ich mich
Hallo Ricardo,
ich wollte meine Fäden zu diesem Thema wieder aufnehmen und meine
bisherigen Erkenntnisse so zusammenstellen, dass jmd. anderes auch etwas
damit anfangen kann (und ich kein Flaschenhals bin).
Da ich mich seit 1 Jahr nicht mehr richtige damit beschäftigt habe,
scheitere ich an einem
Am 18.06.19 um 17:46 schrieb Konrad Hinsen:
> Conda uses the same approach as Python's virtualenv: create a seperate
> Python installation made up mainly of linke to files shared with other
> such installations.
>
> We could probably do something similar in Guix as well, assuming we can
> make the
Hi Pjotr,
> It would be interesting to see how others solve this problem.
> Including Nix and Conda.
Conda uses the same approach as Python's virtualenv: create a seperate
Python installation made up mainly of linke to files shared with other
such installations.
We could probably do something si
Am 17.06.19 um 20:34 schrieb Ricardo Wurmus:
> Yes, those solutions aren’t pretty but they are well understood and have
> no surprising behaviour, which is what I meant. GUIX_PYTHON2/3PATH
> would be a boring solution that works just like the others I listed.
TL;DR: Got for GUIX_PYTHONPATH_3_7.
Ludovic Courtès writes:
>> GUIX_PYTHON2PATH / GUIX_PYTHON3PATH is as solution that’s really just a
>> variant of what we’ve been doing all along (with PYTHONPATH), and it has
>> precedent in GUIX_LOCPATH, GUIX_GTK2_IM_MODULE_FILE, and
>> GUIX_GTK3_IM_MODULE_FILE. It’s a simple solution and rem
On Mon, Jun 17, 2019 at 12:20:12PM +0200, Konrad Hinsen wrote:
> Hi Ludo,
>
> > How does virtualenv work, if not by setting PYTHONPATH?
>
> It creates a new filetree corresponding to a complete new Python
> installation, and the uses soft links to share most of the actual files
> with the parent
Am 17.06.19 um 11:03 schrieb Ludovic Courtès:
> How does virtualenv work, if not by setting PYTHONPATH?
Appending to Konrads answer: Making the profile a fake virtualenv does
not work. See my analysis part 2
(50179a9a-4e29-e729-ee49-ccbb90d9e...@crazy-compilers.com).
--
Regards
Hartmut Goebel
|
Hi Ludo,
> How does virtualenv work, if not by setting PYTHONPATH?
It creates a new filetree corresponding to a complete new Python
installation, and the uses soft links to share most of the actual files
with the parent installation.
> Setting up an environment all about augmenting the search pa
Hello,
Hartmut Goebel skribis:
> IMO the only sustainable solution it to patch the interpreter
> (Modules/getpath.c) to determine the correct "installation path"
> (profile). I did quite some work on this last year, but had no time to
> finish it. I still have no time for finishing, but I should
Hi Konrad,
Konrad Hinsen skribis:
> Nowadays, in the wider world (beyond Guix), PYTHONPATH is mainly a
> newbie trap. Experienced pythonistas have abandoned it for virtual
> environments. So if it can be turned into a mechanism for supporting
> Guix environments with a name change, I doubt anyon
Hi Hartmut,
>> here’s a half-baked idea that I think is worth considering: let’s patch
>> our Python package to respect GUIX_PYTHONPATH and use GUIX_PYTHONPATH in
>> our wrappers.
>
> I have a *strong* opinion against this, as this would just replace one
> cludge by another one. See below for ra
Am 14.06.19 um 10:14 schrieb Ricardo Wurmus:
I welcome your initiative. Fixing this finally is on my todo-list since
long.
> here’s a half-baked idea that I think is worth considering: let’s patch
> our Python package to respect GUIX_PYTHONPATH and use GUIX_PYTHONPATH in
> our wrappers.
I have a
Hi Ricardo,
> here’s a half-baked idea that I think is worth considering: let’s patch
> our Python package to respect GUIX_PYTHONPATH and use GUIX_PYTHONPATH in
> our wrappers.
...
I agree with the reasoning behind this and at first sight, your proposal
looks good. But real life is always messier
Ludovic Courtès writes:
>> here’s a half-baked idea that I think is worth considering: let’s patch
>> our Python package to respect GUIX_PYTHONPATH and use GUIX_PYTHONPATH in
>> our wrappers.
>
> Oh!
>
> [...]
>
>> So I propose to avoid using PYTHONPATH, which is similarly dangerous as
>> LD_LI
Hello!
Ricardo Wurmus skribis:
> here’s a half-baked idea that I think is worth considering: let’s patch
> our Python package to respect GUIX_PYTHONPATH and use GUIX_PYTHONPATH in
> our wrappers.
Oh!
[...]
> So I propose to avoid using PYTHONPATH, which is similarly dangerous as
> LD_LIBRARY_
Ricardo Wurmus transcribed 2.0K bytes:
> Hi Guix,
>
> here’s a half-baked idea that I think is worth considering: let’s patch
> our Python package to respect GUIX_PYTHONPATH and use GUIX_PYTHONPATH in
> our wrappers.
>
> PYTHONPATH is dangerously inadequate for use in a wrapper. Consider the
> c
Hi Guix,
here’s a half-baked idea that I think is worth considering: let’s patch
our Python package to respect GUIX_PYTHONPATH and use GUIX_PYTHONPATH in
our wrappers.
PYTHONPATH is dangerously inadequate for use in a wrapper. Consider the
case where a user has Numpy installed with Guix but also
19 matches
Mail list logo
