Leo Famulari <l...@famulari.name> writes:

> This is a build time dependency of python-requests-toolbelt when using
> Python 3.5.
> * gnu/packages/python.scm (python-betamax, python2-betamax): New variables.

This LGTM, but I have a couple of off-topic remarks.

The requests input/reference was a bit odd and seems to come from a
python PTH [0] file that sets up the full path to the requests library:

$ cat 
import sys; sys.__plen = len(sys.path)
import sys; new=sys.path[sys.__plen:]; del sys.path[sys.__plen:]; 
p=getattr(sys,'__egginsert',0); sys.path[p:p]=new; sys.__egginsert = p+len(new)

I can load this from a pure environment:

$ ./pre-inst-env guix environment --container --pure --ad-hoc python-betamax 
[env]# python3 -c 'import betamax'

Doing the same when applied to wip-python-build-system results in:

[env]# python3 -c 'import betamax'
Traceback (most recent call last):
  File "<string>", line 1, in <module>
 line 13, in <module>
    from .decorator import use_cassette
 line 4, in <module>
    import requests
ImportError: No module named 'requests'

Can we leverage this mechanism instead of propagating everything? Are
there any drawbacks to doing that?

I'll have to do some more investigation around how those .pth files are
created, but food for thought. Perhaps it only works with eggs?

0: https://docs.python.org/3/library/site.html

Reply via email to