On 23 April 2015 at 03:09, M.-A. Lemburg <m...@egenix.com> wrote: > [adding list back on CC] > > On 22.04.2015 16:11, Christoph Schmitt wrote: >> Am 2015-04-22 12:59, schrieb M.-A. Lemburg: >>> On 22.04.2015 12:38, Robert Collins wrote:
>> That would apply also if namespace_packages would be ignored >> automatically for Python >= 3.3 as you proposed. >> >> As a consequence, two distributions were neccessary. One with >> namespace_packages declared and >> containing an __init__.py (with pkg_resources.declare_namespace) and another >> one without those >> additions. But how does setuptools figure out to leave out the __init__.py >> for non-declard namespace >> packages in the latter case? > > Like I mentioned above: it's probably better for setuptools to handle > this in a consistent way rather than changing all setup.pys. I agree, but consider this situation - on any PEP-420 supporting python Two packages: name.A and name.B. name.A already installed on the machine systemwide using old-style namespace path hacks, and then do a wheel install of name.B. If the wheel for name.B was built expecting PEP-420, it won't be importable after install (because the path manipulation that sets up name as an old-style namespace happens in site.py). If the wheel was built expecting old-style namespaces, but A was installed using PEP-420, then A won't be installable after B is installed (same reason). The point of splitting the place the two are installed is to show that the user may not be able to fix the existing install. So - pip would have to a) detect both styles of package, b) automatically install all installed-but-wrong-style versions to match the site installed ones. And if any of the packages in the namespace only support legacy, everything would be clamped down to legacy. > One detail I'm not sure about is how compatible the two namespace > package techniques really are. The PEP 420 hand waves over possible > differences and only addresses pkgutil, not the setuptools > approach, which is by far more common. For most simply applications > not relying on any of the advanced features, they will most likely > be compatible. They are entirely incompatible. > I guess some experiments are necessary to figure that out. I spent a week last year debugging issues within openstack with namespace packages, local tree imports of same, and both pure venv and split system and venv environments. Some key interesting things: - the setuptools pth files aren't fully venv aware today - potentially fixable but the resulting pth file is fugly, so I decided not worth it. - local tree imports work a heck of a lot better in tox etc with PEP-420 namespaces - PEP-420 namespaces can work on older pythons with importlib, but - PEP-420 and legacy packages being mixed for one namespace doesn't work at all today - in principle fixable via changes to both setuptools and importlib - but it was about here that the other openstack folk said 'ok wow, lets just stop using namespace packages :) I think its a -lot- easier to reason about these things as two entirely separate features. -Rob -- Robert Collins <rbtcoll...@hp.com> Distinguished Technologist HP Converged Cloud _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org https://mail.python.org/mailman/listinfo/distutils-sig
