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. -- Best regards, Michał Górny
signature.asc
Description: This is a digitally signed message part
