Re: Avoiding PYTHONPATH - latest?

[Phil <phil@beadling.co.uk>]

Hi

zimoun writes:

> Just to understand, is your point to be able to mix both “pip install“
> and “guix install”?  If yes, it appears to me a bad idea, choose one or
> the other.

I suppose my point is - system-level use of PYTHONPATH is ill-advised, because
it's prescribed use in Python is for user-level sys.path modifications. An
example of when this causes surprise is creating an environment using
'pip install -e .' will not give a pure environment if PYTHONPATH is set.

I 100% agree it's a bad idea to mix packagers, but pip install's use-cases go
beyond the need to do fixed installs of package@version, provided by Guix.

The use of 'pip install -e .' to create a development environment is
widely (but not exclusively) used in the python community, and
integrates nicely with many python tools (eg pytest).  It's not
essential of course.

Given that Guix profile's can't be edited from within a Guix profile
(for obvious reasons), if I want to edit my code whilst it is installed,
I see the only way to do this is by having a virtual env on top of a
Guix profile that contains only my own module - with the Guix profile
holding Python and all the imports I depend on.

It's not pretty.  So much so that I'm considering if I can live without
'-e', but the workarounds of using sys.append, PYTHONPATH, or even pth
files are, at least in some people's minds, not as clean.

If anyone has worked-out a better setup with Guix/Python, I'm keen to
get advice (hence me floating the (half-baked) idea of using pyvenv.cfg
to create Guix profiles).

There's a 2 year long discussion on a similar topic for the Poetry package
(which also aims to replace pip, for different reasons than Guix):
https://github.com/python-poetry/poetry/issues/34

Things get a bit heated, which isn't helpful, but it does illustrate how
dearly some python fans take their ability to use pip's developer setup
- I'm more pragmatic and looking for workable solutions, preferably without 
fighting Python stock features just to keep Guix happy ;-)

Perhaps the simple answer here is never mix pip and guix, and setup your
development environment so there is never a requirement on pip.  But this is
a limitation to people used to working this way.

If nothing else, personally, it was a good off-the-deep-end way to get under the
covers of Guix's treatment of python and python packages :-)