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