Gentoo Archives: gentoo-python

From: Mike Gilbert <floppym@g.o>
To: "Michał Górny" <mgorny@g.o>
Cc: gentoo-python <gentoo-python@l.g.o>, python <python@g.o>
Subject: Re: [gentoo-python] RFC: Providing explicit support for namespaces
Date: Sun, 07 May 2017 16:39:49
Message-Id: CAJ0EP40f-Sn4WmbOxp3FOxUAvzMTBgUcBSJ3LVAMQwje1U-k8w@mail.gmail.com
In Reply to: [gentoo-python] RFC: Providing explicit support for namespaces by "Michał Górny"
1 On Fri, May 5, 2017 at 7:55 AM, Michał Górny <mgorny@g.o> wrote:
2 > Hi, everyone.
3 >
4 > Python namespaces are an ugly hack that Python upstreams do mostly
5 > to look more enterprise'y and support installing subpackages of a common
6 > parent package in different locations (i.e. zope.*, ...). For more
7 > information on them, read PEP 420 [1], Python Packaging Guide [2]
8 > and our wiki page [3].
9 >
10 > So far we haven't been really providing any special support for
11 > namespaces. We were rather relying on things magically working out
12 > of the box and applying distutils_install_for_testing whenever they
13 > weren't. However, this was really a 'big hammer' solution -- not very
14 > precise, not very reliable.
15 >
16 > I've been working on adding missing test dependencies of yet another
17 > zope-related package lately [4] and hit a few more issues with namespace
18 > of zope.*. It turned out that due to some random changes in Python 3.5+,
19 > 'setup.py install --home=...' (used for d_i_f_t) no longer correctly
20 > established namespaces for our use and I had to use 'setup.py develop'
21 > instead for zope.testrunner [5]. However, even this didn't work for
22 > zope.exceptions where I would probably have to also deploy 'setup.py
23 > easy_install' or add requirements to setup.py.
24 >
25 > So I've went ahead and explored other possibilities. I've figured out
26 > that at the moment namespace packages work on old Python versions
27 > because of *.pth files installed by setuptools along with the packages.
28 > However, this hack might be deprecated [6]. Also, it seemed to be
29 > the source of problems with Python 3.5+.
30 >
31 >
32 > You can see what I did on the PR [4]. It boils down to:
33 >
34 > 1. Adding dev-python/namespace-zope package (name selected to avoid
35 > collisions with potential packages) that installs setuptools-compliant
36 > __init__.py.
37 >
38 > 2. Removing *.pth files from dev-python/zope* and making those packages
39 > depend on dev-python/namespace-zope instead.
40 >
41 > This done, I was able to get the tests on the 5 zope packages to pass
42 > on all Python implementations without any additional logic
43 > (in particular, without a call to d_i_f_t).
44 >
45 >
46 > If you consider this an acceptable solution to the namespace problem,
47 > I'd like to set up the following guidelines for dealing with namespaces:
48 >
49 > 1. A single package should be selected to 'hold' the namespace. It can
50 > be a common package for the ns (e.g. dev-python/logilab-common)
51 > or a dedicated dev-python/namespace-* package.
52 >
53 > 2. This package should install appropriate __init__.py for the
54 > namespace. The contents should be selected to match the namespace logic
55 > used by the packages (pkgutil vs setuptools).
56 >
57 > 3. All subpackages in the namespace should RDEP (+ DEP) on this package,
58 > and not install *-nspkg.pth files.
59 >
60 >
61 > Your thoughts?
62
63 Thank you for the well-organized walkthrough. Your approach makes sense to me.