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