"setup.py install" does not coexist nicely with "pip install" for namespace packages

[theacodes]

An exhaustive test of how namespace package installation works across pip install, pip install -e, python setup.py install, and python setup.py devlop reveals that the following cases fail:

1. Installing one package in the namespace using setup.py and the other using pip (order does not matter).
2. Installing one package in the namespace using setup.py develop and the other using setup.py install (order does not matter).

You can see the entire matrix of scenarios here. Note that pep420 packages are failing on 2.x presumably because of #406.

Context: pypa/packaging.python.org#265 (comment)

[jaraco]

Thanks for investing the time to catalog these shortcomings.

That's right. setup.py install invokes the egg protocol which was famously deprecated. I'd say it's unsupported to support mixed-method environments. It's difficult enough trying to support namespace packages in just one or the other modes.

First and foremost, I want to support pip install ., pip install -e .. Secondarily, I want to support pure non-pip installs through setup.py install and setup.py develop, although I consider that model (soft) deprecated and will eventually be superseded by pip entirely.

There's a proposal to actually replace easy_install with pip install in #917, which if that's viable would eliminate these differences.

I welcome others to dive in and work on #917 or otherwise try to make these modes work together, but to what advantage? Can you see any reason not to cut our losses and focus on the future?

[theacodes]

That's right. setup.py install invokes the egg protocol which was famously deprecated. I'd say it's unsupported to support mixed-method environments. It's difficult enough trying to support namespace packages in just one or the other modes.

Cool - this was basically the guidance I was looking for. When I add documentation to the user guide about namespace packages I want to be able to authoritatively assert that this is unsupported.

First and foremost, I want to support pip install ., pip install -e .

Looks like that case works. :) (except for pep420 packages in 2.7)

Secondarily, I want to support pure non-pip installs through setup.py install and setup.py develop

That case seems to be failing.

There's a proposal to actually replace easy_install with pip install in #917, which if that's viable would eliminate these differences.

Cool, I'll keep an eye on this.

Can you see any reason not to cut our losses and focus on the future?

I actually would love to live in a world where pip install and pip install -e is all we have to worry about. My goal here is to figure out what works today and what doesn't and what we plan on supporting in the future so that I can write an authoritative guide on how to do namespace packages in Python.

[jaraco]

Thanks for this help, and good luck. I'm going to close this ticket, but feel free (anyone) to file a ticket about the outstanding issues with non-pip installs. I personally used these extensively until I recently re-tooled my workflows to rely on pip.

[theacodes]

Thanks for this help, and good luck.

Thank you! Python packaging is complicated and I'm happy people like you are around.

(& I'll probably need the luck)