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. |