1 |
On czw, 2017-05-18 at 15:07 -0700, Daniel Campbell wrote: |
2 |
> On Fri, May 12, 2017 at 08:32:53PM +0200, Michał Górny wrote: |
3 |
> > On czw, 2017-05-11 at 11:47 +0700, Alex Turbov wrote: |
4 |
> > > DEPEND=( doc? |
5 |
> > > || ( |
6 |
> > > ( |
7 |
> > > dev-python/sphinx[python_targets_python2_7] |
8 |
> > > # NOTE This packages provide extensions for Sphinx |
9 |
> > > dev-python/rst-linker[python_targets_python2_7] |
10 |
> > > dev-python/jaraco-packaging[python_targets_python2_7] |
11 |
> > > ) |
12 |
> > > ( |
13 |
> > > dev-python/sphinx[python_targets_python3_5] |
14 |
> > > dev-python/rst-linker[python_targets_python3_5] |
15 |
> > > dev-python/jaraco-packaging[python_targets_python3_5] |
16 |
> > > ) |
17 |
> > > ( |
18 |
> > > dev-python/sphinx[python_targets_python3_6] |
19 |
> > > dev-python/rst-linker[python_targets_python3_6] |
20 |
> > > dev-python/jaraco-packaging[python_targets_python3_6] |
21 |
> > > ) |
22 |
> > > ) |
23 |
> > > ) |
24 |
> > > |
25 |
> > |
26 |
> > One more thing I've missed in my initial mail. The other problem with |
27 |
> > this solution (alone) is that it doesn't enforce the implementation that |
28 |
> > satisfied the dependency. |
29 |
> > |
30 |
> > Let's take a simple example. You've built sphinx for 2.7+3.5 but rst- |
31 |
> > linker and jaraco-packaging for 3.5 only. The dependency is satisfied |
32 |
> > because the 3.5 branch matches. However, you have no rule to enforce |
33 |
> > 3.5, so sphinx could be actually called with 2.7 and fail. |
34 |
> > |
35 |
> > This is a generic problem that was pretty much solved by python-any-r1. |
36 |
> > I think we should be able to copy the most important pieces of the API |
37 |
> > to python-r1 to achieve something similar, i.e. add python_gen_any_dep |
38 |
> > to generate the depstrings and make python_setup aware of |
39 |
> > python_check_deps(). Then the above would be written alike: |
40 |
> > |
41 |
> > DEPEND="doc? ( $(python_gen_any_dep ' |
42 |
> > dev-python/sphinx[${PYTHON_USEDEP}] |
43 |
> > dev-python/rst-linker[${PYTHON_USEDEP}] |
44 |
> > dev-python/jaraco-packaging[${PYTHON_USEDEP}] |
45 |
> > ') )" |
46 |
> > |
47 |
> > python_check_deps() { |
48 |
> > has_version "dev-python/sphinx[${PYTHON_USEDEP}]" && |
49 |
> > has_version "dev-python/rst-linker[${PYTHON_USEDEP}]" && |
50 |
> > has_version "dev-python/jaraco-packaging[${PYTHON_USEDEP}]" |
51 |
> > } |
52 |
> > |
53 |
> > python_setup would verify which implementation has the dependencies |
54 |
> > satisfied, and set it for the common code building docs. |
55 |
> > |
56 |
> > However: |
57 |
> > |
58 |
> > 1. I think it would work. However, I can't be sure until I implement it, |
59 |
> > and even then I might miss something. |
60 |
> > |
61 |
> > 2. It's a significant extension to the API, and kinda goes against |
62 |
> > the goal of making the eclass simpler. However, it mostly fits what is |
63 |
> > in python-any-r1 already, so at least it doesn't introduce a new API. |
64 |
> > |
65 |
> > So I'd like others to chime in and let me know whether they consider |
66 |
> > this a worthwhile addition before I start working on it. |
67 |
> > |
68 |
> > -- |
69 |
> > Best regards, |
70 |
> > Michał Górny |
71 |
> |
72 |
> Would this bloat python-r1 too much? I understand the need to keep |
73 |
> eclasses small and efficient. This looks like it might work, and I'm |
74 |
> willing to test it, though I'd need some time to learn how to properly |
75 |
> test Python packages. Is #gentoo-python a good place to seek guidance, |
76 |
> after looking through docs? |
77 |
|
78 |
That's the problem I'm most worried of. On the other hand, it's pretty |
79 |
much what we have in python-any-r1 already, so expect for physical code |
80 |
increase, we're mostly just extending an existing API into additional |
81 |
eclass. |
82 |
|
83 |
> Is this a unique-enough case to justify a python-doc eclass? It looks |
84 |
> like it would depend on python-any* or python-r* anyway, so maybe it's a |
85 |
> bit redundant. It's an option, though. |
86 |
|
87 |
I don't think so. It's a complex problem with many different |
88 |
implementation details. Even if we wrote an eclass, it would either do |
89 |
confusingly little, or have more conditionals than code. |
90 |
|
91 |
> |
92 |
> I hadn't considered the dependency <-> implementation relationship; nice |
93 |
> catch! If what you wrote above is as clean as we can get it, I'm |
94 |
> willing to help you on it. I'm just not sure how I'd be most helpful |
95 |
> since I've never written an eclass. |
96 |
|
97 |
No need to do that. As I said, it's mostly copy-paste from python-any-r1 |
98 |
with little changes. I'll get to that soon enough. |
99 |
|
100 |
|
101 |
-- |
102 |
Best regards, |
103 |
Michał Górny |