[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gentoo-dev
Subject:    Re: [gentoo-dev] Should Sphinx really depends on PYTHON_COMPAT/PYTHON_USEDEP for `dev-python/*` ebui
From:       Michał_Górny <mgorny () gentoo ! org>
Date:       2017-05-18 22:30:58
Message-ID: 1495146658.24214.3.camel () gentoo ! org
[Download RAW message or body]


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" (application/pgp-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]