Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Possible bug regarding namespace packages #430

Closed
IwanVosloo opened this issue Dec 28, 2016 · 5 comments
Closed

Possible bug regarding namespace packages #430

IwanVosloo opened this issue Dec 28, 2016 · 5 comments

Comments

@IwanVosloo
Copy link

I have a case where code in one module in a namespace package cannot import code from another module in a different setuptools distribution that shares the same namespace package.

I actually filed an issue with setuptools here: /pypa/setuptools/issues/900, but i cannot be sure its not a tox issue because: if I do by hand what I think tox does to create a virtualenv and install the packages - everything works. It only breaks when tox does it.

In order not to create duplication I leave the details of the bug in /pypa/setuptools/issues/900.

OS: Ubuntu 16.04

Python: 3.5 (it works on 2.7)

pip list (in the dev virtualenv):

pip (9.0.1)
pkg-resources (0.0.0)
pluggy (0.4.0)
py (1.4.32)
setuptools (32.3.0)
tox (2.5.0)
virtualenv (15.1.0)
wheel (0.30.0a0)

pip list (in the created py35 virtualenv):

nspace-three (1.0.0)
nspace-two (1.0.0)
pip (9.0.1)
setuptools (32.3.0)
wheel (0.29.0)

@obestwalter obestwalter added the needs:discussion It's not quite clear if and how this should be done label Dec 28, 2016
@obestwalter
Copy link
Member

Hi @IwanVosloo thanks for the report. This one sounds tricky. I'll set it to incomplete until it is clear where the root of problem lies.

@IwanVosloo
Copy link
Author

When I tried to replicate what tox would do, I basically did:

mkvirtualenv test -p $(which python3)
pip install /path/to/sdist.tarfile_of_nspace_two

As I understand it, that is what tox does. The pip install will also pull in nspace-three because ~/.pip/pip.config is set to find the other sdist tarball as well, and the dependency pulls it in.

Do I understand what tox does here correctly?

@obestwalter
Copy link
Member

obestwalter commented Dec 28, 2016

I don't know exactly yet what tox does there - I am mainly bug triaging since I joined the project and have not yet worked my way into the depth of the code. I never used namespace packages yet either, so there are two unknowns for me.

I don't know if this is a good idea, but maybe a good approach to make progress with this could be to create a reproducer in form of a test case similar like e.g. in the venv tests. If you build a test that leaves out the mocking you could reproduce the problem and even step through it in a debugger, to see what happens. If we have something like that, you might even be able to fix it yourself and send a PR.

@IwanVosloo
Copy link
Author

Hello @obestwalter , I have managed to reproduce this now without tox, so I am closing the issue. Thanks.

@obestwalter
Copy link
Member

Thank you Iwan :)

@obestwalter obestwalter added invalid and removed needs:discussion It's not quite clear if and how this should be done labels Jan 5, 2017
@tox-dev tox-dev locked and limited conversation to collaborators Jan 14, 2021
# for free to subscribe to this conversation on GitHub. Already have an account? #.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants