On 05/18/2017 03:30 PM, Michał Górny wrote:
> On czw, 2017-05-18 at 15:07 -0700, Daniel Campbell wrote:
>> On Fri, May 12, 2017 at 08:32:53PM +0200, Michał Górny wrote:
>>> On czw, 2017-05-11 at 11:47 +0700, Alex Turbov wrote:
>>>> DEPEND=( doc?
>>>> || (
>>>> (
>>>> dev-python/sphinx[python_targets_python2_7]
>>>> # NOTE This packages provide extensions for Sphinx
>>>> dev-python/rst-linker[python_targets_python2_7]
>>>> dev-python/jaraco-packaging[python_targets_python2_7]
>>>> )
>>>> (
>>>> dev-python/sphinx[python_targets_python3_5]
>>>> dev-python/rst-linker[python_targets_python3_5]
>>>> dev-python/jaraco-packaging[python_targets_python3_5]
>>>> )
>>>> (
>>>> dev-python/sphinx[python_targets_python3_6]
>>>> dev-python/rst-linker[python_targets_python3_6]
>>>> dev-python/jaraco-packaging[python_targets_python3_6]
>>>> )
>>>> )
>>>> )
>>>>
>>>
>>> One more thing I've missed in my initial mail. The other problem with
>>> this solution (alone) is that it doesn't enforce the implementation that
>>> satisfied the dependency.
>>>
>>> Let's take a simple example. You've built sphinx for 2.7+3.5 but rst-
>>> linker and jaraco-packaging for 3.5 only. The dependency is satisfied
>>> because the 3.5 branch matches. However, you have no rule to enforce
>>> 3.5, so sphinx could be actually called with 2.7 and fail.
>>>
>>> This is a generic problem that was pretty much solved by python-any-r1.
>>> I think we should be able to copy the most important pieces of the API
>>> to python-r1 to achieve something similar, i.e. add python_gen_any_dep
>>> to generate the depstrings and make python_setup aware of
>>> python_check_deps(). Then the above would be written alike:
>>>
>>> DEPEND="doc? ( $(python_gen_any_dep '
>>> dev-python/sphinx[${PYTHON_USEDEP}]
>>> dev-python/rst-linker[${PYTHON_USEDEP}]
>>> dev-python/jaraco-packaging[${PYTHON_USEDEP}]
>>> ') )"
>>>
>>> python_check_deps() {
>>> has_version "dev-python/sphinx[${PYTHON_USEDEP}]" &&
>>> has_version "dev-python/rst-linker[${PYTHON_USEDEP}]" &&
>>> has_version "dev-python/jaraco-packaging[${PYTHON_USEDEP}]"
>>> }
>>>
>>> python_setup would verify which implementation has the dependencies
>>> satisfied, and set it for the common code building docs.
>>>
>>> However:
>>>
>>> 1. I think it would work. However, I can't be sure until I implement it,
>>> and even then I might miss something.
>>>
>>> 2. It's a significant extension to the API, and kinda goes against
>>> the goal of making the eclass simpler. However, it mostly fits what is
>>> in python-any-r1 already, so at least it doesn't introduce a new API.
>>>
>>> So I'd like others to chime in and let me know whether they consider
>>> this a worthwhile addition before I start working on it.
>>>
>>> --
>>> Best regards,
>>> Michał Górny
>>
>> Would this bloat python-r1 too much? I understand the need to keep
>> eclasses small and efficient. This looks like it might work, and I'm
>> willing to test it, though I'd need some time to learn how to properly
>> test Python packages. Is #gentoo-python a good place to seek guidance,
>> after looking through docs?
>
> That's the problem I'm most worried of. On the other hand, it's pretty
> much what we have in python-any-r1 already, so expect for physical code
> increase, we're mostly just extending an existing API into additional
> eclass.
>
>> Is this a unique-enough case to justify a python-doc eclass? It looks
>> like it would depend on python-any* or python-r* anyway, so maybe it's a
>> bit redundant. It's an option, though.
>
> I don't think so. It's a complex problem with many different
> implementation details. Even if we wrote an eclass, it would either do
> confusingly little, or have more conditionals than code.
>
>>
>> I hadn't considered the dependency <-> implementation relationship; nice
>> catch! If what you wrote above is as clean as we can get it, I'm
>> willing to help you on it. I'm just not sure how I'd be most helpful
>> since I've never written an eclass.
>
> No need to do that. As I said, it's mostly copy-paste from python-any-r1
> with little changes. I'll get to that soon enough.
>
>
Sounds great; given its simplicity I'm sure we can wait a little while.
Thanks for reconsidering. If there's anything I can do to help, please
let me know.-- Daniel Campbell - Gentoo Developer OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6
signature.asc
Description: OpenPGP digital signature
