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órnyWould 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? 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 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.
signature.asc
Description: Digital signature
