public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
* [gentoo-dev] Should Sphinx really depends on PYTHON_COMPAT/PYTHON_USEDEP for `dev-python/*` ebuilds?
@ 2017-05-11  4:47 Alex Turbov
  2017-05-11  7:51 ` Michał Górny
  2017-05-12 18:32 ` Michał Górny
  0 siblings, 2 replies; 15+ messages in thread
From: Alex Turbov @ 2017-05-11  4:47 UTC (permalink / raw
  To: gentoo-dev; +Cc: Michał Górny

[-- Attachment #1: Type: text/plain, Size: 3669 bytes --]

Hi Gentoo devs,

I'd like to discuss one thing I've concernted for a long time already.
Recently I've done some `dev-python` ebuild. And as most Python packages
it also uses `dev-python/sphinx` to produce documentation. I want to note
that my primary (and default) Python version is 3.5 and I have some 2.7
packages
(ebuilds) only because they required by something else (really important to
me).
or when it is dependency of some other Python2-only package.

Unfortunately most of `dev-python/*` packages, to produce docs from RST
files,
have `DEPEND` on `dev-python/sphinx[${PYTHON_USEDEP}]`! However, being a
standalone application (just processing a bunch of RST files to HTMLs),
`/usr/bin/sphinx-build` **do not** actually depeds on `PYTHON_COMPAT` of
the ebuild it used inside! It just needs some/any interpreter it (Sphinx)
was "build" with!

So, nowadays Gentoo has some reeally weired IMO behaviour: to build docs for
some package from `dev-python/*` with `PYTHON_TARGETS` set to (for example)
2.7 and
3.5 Python versions, I have to build Sphinx also **for all enabled Python
versions**
of that package, meanwhile **only one** is needed (and really used)! This
is my
real concern: why I have to waste my disk+time to build `dev-python/*`
packages
with `PYTHON_TARGETS` I'll never use? Some of that packages are actually
dependencies
of other Python2-only packages. In other words, to build docs using Python
**3**
version/build of Sphinx, which is work pretty fine already, for Python2
enabled package,
I have to install a lot of Python-2 packages, dependencies of Sphinx to be
built w/ Python 2,
and enable `python2_7` for packages I've already have as Python3-only,
which in turn could
bring even more strange dependencies into scope.

Thus generally specking, Sphinx dependencies have no relations to `DEPEND`
of particular
`dev-python/*` ebuilds! So, in simple case there is should be enough to
specify

    DEPEND=( doc? ( dev-python/sphinx ) )

for that ebuilds. In some rare cases (like
https://bugs.gentoo.org/show_bug.cgi?id=618162)
Sphinx could use some extensions (plugins) and they also have no any
relation to `PYTHON_COMPAT`
of particular `dev-python/*` ebuild! That plugins to work need just the
same `PYTHON_TARGETS`
as used to build Sphinx. Unfortunately I can't find appropriate helper
function(s) in any
currently present Python reelated eclasses (or am I miss smth?), so I used
the following
dependency spec:

    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]
                )
            )
      )

So, my questions are:

0. am I missed smth? (and there are some other cases, I don't know about)
1. am I missed smth? (and there are some helper functions exist in eclasses
to expess that kind
   of dependencies)
2. I think it would be nice to have some support for Sphinx in eclasses to
simplify ebuilds writing
   (if #1 is false)

Ideas/comments/opinions are really welcome...

[-- Attachment #2: Type: text/html, Size: 4339 bytes --]

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [gentoo-dev] Should Sphinx really depends on PYTHON_COMPAT/PYTHON_USEDEP for `dev-python/*` ebuilds?
  2017-05-11  4:47 [gentoo-dev] Should Sphinx really depends on PYTHON_COMPAT/PYTHON_USEDEP for `dev-python/*` ebuilds? Alex Turbov
@ 2017-05-11  7:51 ` Michał Górny
  2017-05-12  6:20   ` Alex Turbov
  2017-05-13  0:42   ` Daniel Campbell
  2017-05-12 18:32 ` Michał Górny
  1 sibling, 2 replies; 15+ messages in thread
From: Michał Górny @ 2017-05-11  7:51 UTC (permalink / raw
  To: gentoo-dev

[-- Attachment #1: Type: text/plain, Size: 3805 bytes --]

Hi,

Few janitorial notes for a start:

1. please fix your line wrapping since your messages are wrapped twice
now, and it's really hard to read with single words on every second
line;

2. hardcore Python topics belong on gentoo-python@ but I guess we'll
continue here,

3. please keep your messages brief. The first three paragraphs tell
a thing that could be told in one sentence.

On czw, 2017-05-11 at 11:47 +0700, Alex Turbov wrote:
> Thus generally specking, Sphinx dependencies have no relations to `DEPEND`
> of particular
> `dev-python/*` ebuilds! So, in simple case there is should be enough to
> specify
> 
>     DEPEND=( doc? ( dev-python/sphinx ) )
> 
> for that ebuilds. In some rare cases (like
> https://bugs.gentoo.org/show_bug.cgi?id=618162)
> Sphinx could use some extensions (plugins) and they also have no any
> relation to `PYTHON_COMPAT`
> of particular `dev-python/*` ebuild! That plugins to work need just the
> same `PYTHON_TARGETS`
> as used to build Sphinx. Unfortunately I can't find appropriate helper
> function(s) in any
> currently present Python reelated eclasses (or am I miss smth?), so I used
> the following
> dependency spec:
> 
>     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]
>                 )
>             )
>       )

You can't use python_targets directly since it will break when the old
implementations are disabled (and also make it PITA for others to add
new impls).

> 
> So, my questions are:
> 
> 0. am I missed smth? (and there are some other cases, I don't know about)
> 1. am I missed smth? (and there are some helper functions exist in eclasses
> to expess that kind
>    of dependencies)
> 2. I think it would be nice to have some support for Sphinx in eclasses to
> simplify ebuilds writing
>    (if #1 is false)
> 
> Ideas/comments/opinions are really welcome...

Long story short, it's not worth the effort.

Yes, most of the time people specify PYTHON_USEDEP on sphinx needlessly.
 There are two other major cases when you need it though:

1. things like autointerface that interface with packages' code,

2. and packages calling sphinx via 'python /usr/bin/sphinx ...' (i.e.
requiring impl match between python in use and sphinx).

However, tracking the other uses down and figuring them is not worth
the effort. In the end, someone will probably add it back thinking
someone must've missed it. It's too hard to get it right.

In fact, I'm personally leaning towards not building docs at all
in ebuilds. It's practically a wasted effort since most of the time
users read docs online anyway.

Building Sphinx with less implementations than its reverse dependencies
is a corner case. It's not really worth spending hours making sure
depends are 100% strictly correct. The more important goal is to have
things working reliably, and overspecified deps are reliable, i.e.
packages won't fail to build because of them.

-- 
Best regards,
Michał Górny

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 963 bytes --]

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [gentoo-dev] Should Sphinx really depends on PYTHON_COMPAT/PYTHON_USEDEP for `dev-python/*` ebuilds?
  2017-05-11  7:51 ` Michał Górny
@ 2017-05-12  6:20   ` Alex Turbov
  2017-05-12 17:18     ` Michał Górny
  2017-05-13  0:42   ` Daniel Campbell
  1 sibling, 1 reply; 15+ messages in thread
From: Alex Turbov @ 2017-05-12  6:20 UTC (permalink / raw
  To: gentoo-dev

[-- Attachment #1: Type: text/plain, Size: 2983 bytes --]

On Thu, May 11, 2017 at 2:51 PM, Michał Górny <mgorny@gentoo.org> wrote:

> Hi,
>
> Few janitorial notes for a start:
>
> 1. please fix your line wrapping since your messages are wrapped twice
> now, and it's really hard to read with single words on every second
> line;
>

sorry, I don't understand what are you talking about... probably some
problem with your email client (or whatever you use).
I'm using gmail's web UI and see no double wraps...


>
> 2. hardcore Python topics belong on gentoo-python@ but I guess we'll
> continue here,
>

I don't see this ML here: https://gentoo.org/get-involved/mailing-lists/ so
I decided to use `gentoo-dev`


>
> 3. please keep your messages brief. The first three paragraphs tell
> a thing that could be told in one sentence.
>

I've got no idea what message format is "usual" in this ML... from my
experience talking to various "tech support" and bug trackers ppl usually
asking a lot of stupid questions if I wrote just "one sentence"...


>
> You can't use python_targets directly since it will break when the old
> implementations are disabled (and also make it PITA for others to add
> new impls).
>

Ok, what I can use instead?


>
>
> Long story short, it's not worth the effort.
>
> Yes, most of the time people specify PYTHON_USEDEP on sphinx needlessly.
>  There are two other major cases when you need it though:
>
> 1. things like autointerface that interface with packages' code,
>

what are you talking about? (
https://pypi.python.org/pypi/repoze.sphinx.autointerface/ ??)


>
> 2. and packages calling sphinx via 'python /usr/bin/sphinx ...' (i.e.
> requiring impl match between python in use and sphinx).
>

do you mean they are doing it from ebuild?


>
> In fact, I'm personally leaning towards not building docs at all
> in ebuilds. It's practically a wasted effort since most of the time
> users read docs online anyway.
>

unfortunately I'm travelling a lot and really often in places where
Internet connection is far from good. it is why I like to have offline docs
for some packages. moreover I really hate when some docs are not really
offline and want to load google fonts or JS :(


>
> However, tracking the other uses down and figuring them is not worth
> the effort. In the end, someone will probably add it back thinking
> someone must've missed it. It's too hard to get it right.
>

I didn't get what are you talking about...


> Building Sphinx with less implementations than its reverse dependencies
> is a corner case. It's not really worth spending hours making sure
> depends are 100% strictly correct. The more important goal is to have
> things working reliably, and overspecified deps are reliable, i.e.
> packages won't fail to build because of them.
>
>
Ok, seems I've got your point of view, but can't agree w/ it... Well, I
would fight alone w/ it


> --
> Best regards,
> Michał Górny
>

[-- Attachment #2: Type: text/html, Size: 5338 bytes --]

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [gentoo-dev] Should Sphinx really depends on PYTHON_COMPAT/PYTHON_USEDEP for `dev-python/*` ebuilds?
  2017-05-12  6:20   ` Alex Turbov
@ 2017-05-12 17:18     ` Michał Górny
  0 siblings, 0 replies; 15+ messages in thread
From: Michał Górny @ 2017-05-12 17:18 UTC (permalink / raw
  To: gentoo-dev

[-- Attachment #1: Type: text/plain, Size: 3105 bytes --]

On pią, 2017-05-12 at 13:20 +0700, Alex Turbov wrote:
> On Thu, May 11, 2017 at 2:51 PM, Michał Górny <mgorny@gentoo.org> wrote:
> 
> > Hi,
> > 
> > Few janitorial notes for a start:
> > 
> > 1. please fix your line wrapping since your messages are wrapped twice
> > now, and it's really hard to read with single words on every second
> > line;
> > 
> 
> sorry, I don't understand what are you talking about... probably some
> problem with your email client (or whatever you use).
> I'm using gmail's web UI and see no double wraps...

Example from your e-mail (I've added empty lines to prevent gmail from
pretending it's fine):

| that my primary (and default) Python version is 3.5 and I have some 2.7

| packages

| (ebuilds) only because they required by something else (really important to

| me).

Plus, please disable HTML mail. It is possible that this will also fix
text mail format.

> > You can't use python_targets directly since it will break when the old
> > implementations are disabled (and also make it PITA for others to add
> > new impls).
> > 
> 
> Ok, what I can use instead?

No solution for the moment. I have some idea though, and I will shortly
reply to your original e-mail on it.

> > Long story short, it's not worth the effort.
> > 
> > Yes, most of the time people specify PYTHON_USEDEP on sphinx needlessly.
> >  There are two other major cases when you need it though:
> > 
> > 1. things like autointerface that interface with packages' code,
> > 
> 
> what are you talking about? (
> https://pypi.python.org/pypi/repoze.sphinx.autointerface/ ??)

Yes, that one. There could possibly be more.

> > 2. and packages calling sphinx via 'python /usr/bin/sphinx ...' (i.e.
> > requiring impl match between python in use and sphinx).
> > 
> 
> do you mean they are doing it from ebuild?

More often from Makefile or setup.py, or any other wrapper that we have
no direct control of.

> > However, tracking the other uses down and figuring them is not worth
> > the effort. In the end, someone will probably add it back thinking
> > someone must've missed it. It's too hard to get it right.
> > 
> 
> I didn't get what are you talking about...

I mean that it's highly probable that some other developer seeing
dependency on dev-python/sphinx without PYTHON_USEDEP will readd it,
thinking that the developer missed it by mistake.

> 
> 
> > Building Sphinx with less implementations than its reverse dependencies
> > is a corner case. It's not really worth spending hours making sure
> > depends are 100% strictly correct. The more important goal is to have
> > things working reliably, and overspecified deps are reliable, i.e.
> > packages won't fail to build because of them.
> > 
> > 
> 
> Ok, seems I've got your point of view, but can't agree w/ it... Well, I
> would fight alone w/ it
> 

Just to be clear, I'm not opposed to accepting fixes if you want to work
on them. I'm just saying you can expect an uphill battle, and not much
of help.

-- 
Best regards,
Michał Górny

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 963 bytes --]

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [gentoo-dev] Should Sphinx really depends on PYTHON_COMPAT/PYTHON_USEDEP for `dev-python/*` ebuilds?
  2017-05-11  4:47 [gentoo-dev] Should Sphinx really depends on PYTHON_COMPAT/PYTHON_USEDEP for `dev-python/*` ebuilds? Alex Turbov
  2017-05-11  7:51 ` Michał Górny
@ 2017-05-12 18:32 ` Michał Górny
  2017-05-18 22:07   ` Daniel Campbell
  1 sibling, 1 reply; 15+ messages in thread
From: Michał Górny @ 2017-05-12 18:32 UTC (permalink / raw
  To: gentoo-dev

[-- Attachment #1: Type: text/plain, Size: 2811 bytes --]

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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 963 bytes --]

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [gentoo-dev] Should Sphinx really depends on PYTHON_COMPAT/PYTHON_USEDEP for `dev-python/*` ebuilds?
  2017-05-11  7:51 ` Michał Górny
  2017-05-12  6:20   ` Alex Turbov
@ 2017-05-13  0:42   ` Daniel Campbell
  2017-05-13  1:28     ` Dale
  2017-05-13  7:32     ` Michał Górny
  1 sibling, 2 replies; 15+ messages in thread
From: Daniel Campbell @ 2017-05-13  0:42 UTC (permalink / raw
  To: gentoo-dev


[-- Attachment #1.1: Type: text/plain, Size: 1241 bytes --]

On 05/11/2017 12:51 AM, Michał Górny wrote:
> In fact, I'm personally leaning towards not building docs at all
> in ebuilds. It's practically a wasted effort since most of the time
> users read docs online anyway.

I believe that's a little myopic; a user (or even developer) may not
have Internet access all the time, or may not have it in their primary
development environment. Having a copy of the docs locally (the entire
point of USE="doc") is super valuable to have when you're away from the
network. I'm sure I'm not alone as one of the people who uses the flag
and appreciates the work that goes into making sure said flag works.

Sure, we could yank out every single USE="doc", but then we lose a nice
feature of the tree and users are back to either (a) trawling the Web to
find the project site, then hope they have docs in a separate download,
or (b) we end up with foo+1 packages, one extra for any package that has
documentation. Neither are particularly good solutions; Debian has done
the latter and it results in a huge number of packages for little gain.
-- 
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C  1DE4 6F7A 9091 1EA0 55D6


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [gentoo-dev] Should Sphinx really depends on PYTHON_COMPAT/PYTHON_USEDEP for `dev-python/*` ebuilds?
  2017-05-13  0:42   ` Daniel Campbell
@ 2017-05-13  1:28     ` Dale
  2017-05-13  7:32     ` Michał Górny
  1 sibling, 0 replies; 15+ messages in thread
From: Dale @ 2017-05-13  1:28 UTC (permalink / raw
  To: gentoo-dev

Daniel Campbell wrote:
> On 05/11/2017 12:51 AM, Michał Górny wrote:
>> In fact, I'm personally leaning towards not building docs at all
>> in ebuilds. It's practically a wasted effort since most of the time
>> users read docs online anyway.
> I believe that's a little myopic; a user (or even developer) may not
> have Internet access all the time, or may not have it in their primary
> development environment. Having a copy of the docs locally (the entire
> point of USE="doc") is super valuable to have when you're away from the
> network. I'm sure I'm not alone as one of the people who uses the flag
> and appreciates the work that goes into making sure said flag works.
>
> Sure, we could yank out every single USE="doc", but then we lose a nice
> feature of the tree and users are back to either (a) trawling the Web to
> find the project site, then hope they have docs in a separate download,
> or (b) we end up with foo+1 packages, one extra for any package that has
> documentation. Neither are particularly good solutions; Debian has done
> the latter and it results in a huge number of packages for little gain.

As a long term user, I always look at the docs first.  One reason, the
docs should match the version I have installed.  If a package has
changed recently, the online docs become version dependent which makes
it harder to find online.  I've actually ran into that before when I'm
googling trying to get something to work to only find out that the way
things are set up has changed and no longer applies to what I have
installed. 

Having the docs included when available should be required. 

Dale

:-)  :-) 


^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [gentoo-dev] Should Sphinx really depends on PYTHON_COMPAT/PYTHON_USEDEP for `dev-python/*` ebuilds?
  2017-05-13  0:42   ` Daniel Campbell
  2017-05-13  1:28     ` Dale
@ 2017-05-13  7:32     ` Michał Górny
  2017-05-18  4:44       ` Daniel Campbell
  1 sibling, 1 reply; 15+ messages in thread
From: Michał Górny @ 2017-05-13  7:32 UTC (permalink / raw
  To: gentoo-dev

[-- Attachment #1: Type: text/plain, Size: 1405 bytes --]

On pią, 2017-05-12 at 17:42 -0700, Daniel Campbell wrote:
> On 05/11/2017 12:51 AM, Michał Górny wrote:
> > In fact, I'm personally leaning towards not building docs at all
> > in ebuilds. It's practically a wasted effort since most of the time
> > users read docs online anyway.
> 
> I believe that's a little myopic; a user (or even developer) may not
> have Internet access all the time, or may not have it in their primary
> development environment. Having a copy of the docs locally (the entire
> point of USE="doc") is super valuable to have when you're away from the
> network. I'm sure I'm not alone as one of the people who uses the flag
> and appreciates the work that goes into making sure said flag works.
> 
> Sure, we could yank out every single USE="doc", but then we lose a nice
> feature of the tree and users are back to either (a) trawling the Web to
> find the project site, then hope they have docs in a separate download,
> or (b) we end up with foo+1 packages, one extra for any package that has
> documentation. Neither are particularly good solutions; Debian has done
> the latter and it results in a huge number of packages for little gain.

The Python team mostly focuses on providing packages for dependencies of
other Gentoo packages, not direct Python development. We do not have
the manpower to go above that.

-- 
Best regards,
Michał Górny

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 963 bytes --]

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [gentoo-dev] Should Sphinx really depends on PYTHON_COMPAT/PYTHON_USEDEP for `dev-python/*` ebuilds?
  2017-05-13  7:32     ` Michał Górny
@ 2017-05-18  4:44       ` Daniel Campbell
  2017-05-18  5:10         ` Michał Górny
  0 siblings, 1 reply; 15+ messages in thread
From: Daniel Campbell @ 2017-05-18  4:44 UTC (permalink / raw
  To: gentoo-dev

[-- Attachment #1: Type: text/plain, Size: 2078 bytes --]

On Sat, May 13, 2017 at 09:32:46AM +0200, Michał Górny wrote:
> On pią, 2017-05-12 at 17:42 -0700, Daniel Campbell wrote:
> > On 05/11/2017 12:51 AM, Michał Górny wrote:
> > > In fact, I'm personally leaning towards not building docs at all
> > > in ebuilds. It's practically a wasted effort since most of the time
> > > users read docs online anyway.
> > 
> > I believe that's a little myopic; a user (or even developer) may not
> > have Internet access all the time, or may not have it in their primary
> > development environment. Having a copy of the docs locally (the entire
> > point of USE="doc") is super valuable to have when you're away from the
> > network. I'm sure I'm not alone as one of the people who uses the flag
> > and appreciates the work that goes into making sure said flag works.
> > 
> > Sure, we could yank out every single USE="doc", but then we lose a nice
> > feature of the tree and users are back to either (a) trawling the Web to
> > find the project site, then hope they have docs in a separate download,
> > or (b) we end up with foo+1 packages, one extra for any package that has
> > documentation. Neither are particularly good solutions; Debian has done
> > the latter and it results in a huge number of packages for little gain.
> 
> The Python team mostly focuses on providing packages for dependencies of
> other Gentoo packages, not direct Python development. We do not have
> the manpower to go above that.
> 
> -- 
> Best regards,
> Michał Górny

Ah, well that at least explains why you're not interested in it.
Dependency management alone can be tough; I've not noticed any Python
issues, so it seems like you guys do well. :) If you don't mind me
asking, what would it take to solve the USE="doc" issue to the Python
team's standard? I have some personal interest in Python and wouldn't
mind adding 'doc' support for Python packages that users request docs
for.

Maybe others are willing to join me on this. Is that something we can
make happen without getting in anyone's hair?

~zlg

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [gentoo-dev] Should Sphinx really depends on PYTHON_COMPAT/PYTHON_USEDEP for `dev-python/*` ebuilds?
  2017-05-18  4:44       ` Daniel Campbell
@ 2017-05-18  5:10         ` Michał Górny
  2017-05-18  6:23           ` Alex Turbov
  0 siblings, 1 reply; 15+ messages in thread
From: Michał Górny @ 2017-05-18  5:10 UTC (permalink / raw
  To: gentoo-dev

[-- Attachment #1: Type: text/plain, Size: 2571 bytes --]

On śro, 2017-05-17 at 21:44 -0700, Daniel Campbell wrote:
> On Sat, May 13, 2017 at 09:32:46AM +0200, Michał Górny wrote:
> > On pią, 2017-05-12 at 17:42 -0700, Daniel Campbell wrote:
> > > On 05/11/2017 12:51 AM, Michał Górny wrote:
> > > > In fact, I'm personally leaning towards not building docs at all
> > > > in ebuilds. It's practically a wasted effort since most of the time
> > > > users read docs online anyway.
> > > 
> > > I believe that's a little myopic; a user (or even developer) may not
> > > have Internet access all the time, or may not have it in their primary
> > > development environment. Having a copy of the docs locally (the entire
> > > point of USE="doc") is super valuable to have when you're away from the
> > > network. I'm sure I'm not alone as one of the people who uses the flag
> > > and appreciates the work that goes into making sure said flag works.
> > > 
> > > Sure, we could yank out every single USE="doc", but then we lose a nice
> > > feature of the tree and users are back to either (a) trawling the Web to
> > > find the project site, then hope they have docs in a separate download,
> > > or (b) we end up with foo+1 packages, one extra for any package that has
> > > documentation. Neither are particularly good solutions; Debian has done
> > > the latter and it results in a huge number of packages for little gain.
> > 
> > The Python team mostly focuses on providing packages for dependencies of
> > other Gentoo packages, not direct Python development. We do not have
> > the manpower to go above that.
> > 
> > -- 
> > Best regards,
> > Michał Górny
> 
> Ah, well that at least explains why you're not interested in it.
> Dependency management alone can be tough; I've not noticed any Python
> issues, so it seems like you guys do well. :) If you don't mind me
> asking, what would it take to solve the USE="doc" issue to the Python
> team's standard? I have some personal interest in Python and wouldn't
> mind adding 'doc' support for Python packages that users request docs
> for.
> 
> Maybe others are willing to join me on this. Is that something we can
> make happen without getting in anyone's hair?
> 

For a start, it'd be nice to figure all the stuff out in detail,
and document it -- when USEDEP is needed, not needed, when we need
something else (like the plugin case). Once that is done, it's just
a matter of checking and fixing existing packages, and being patient
with devs doing the same mistakes again ;-).

-- 
Best regards,
Michał Górny

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 963 bytes --]

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [gentoo-dev] Should Sphinx really depends on PYTHON_COMPAT/PYTHON_USEDEP for `dev-python/*` ebuilds?
  2017-05-18  5:10         ` Michał Górny
@ 2017-05-18  6:23           ` Alex Turbov
  2017-05-18  6:46             ` Michał Górny
  0 siblings, 1 reply; 15+ messages in thread
From: Alex Turbov @ 2017-05-18  6:23 UTC (permalink / raw
  To: gentoo-dev

[-- Attachment #1: Type: text/plain, Size: 3194 bytes --]

As for me I'm doing few Python projects and as I said before I prefer to
have (real) offline docs, cuz often visit places far from "civilization"
and where 150Kib/s considered as pretty fast Internet connection. Also I'm
very patient on keeping my Gentoo system under control and minimized
(eliminating unnecessary dependencies and files). I could help with adding
patches and bug reports for packages I use.

On Thu, May 18, 2017 at 12:10 PM, Michał Górny <mgorny@gentoo.org> wrote:

> On śro, 2017-05-17 at 21:44 -0700, Daniel Campbell wrote:
> > On Sat, May 13, 2017 at 09:32:46AM +0200, Michał Górny wrote:
> > > On pią, 2017-05-12 at 17:42 -0700, Daniel Campbell wrote:
> > > > On 05/11/2017 12:51 AM, Michał Górny wrote:
> > > > > In fact, I'm personally leaning towards not building docs at all
> > > > > in ebuilds. It's practically a wasted effort since most of the time
> > > > > users read docs online anyway.
> > > >
> > > > I believe that's a little myopic; a user (or even developer) may not
> > > > have Internet access all the time, or may not have it in their
> primary
> > > > development environment. Having a copy of the docs locally (the
> entire
> > > > point of USE="doc") is super valuable to have when you're away from
> the
> > > > network. I'm sure I'm not alone as one of the people who uses the
> flag
> > > > and appreciates the work that goes into making sure said flag works.
> > > >
> > > > Sure, we could yank out every single USE="doc", but then we lose a
> nice
> > > > feature of the tree and users are back to either (a) trawling the
> Web to
> > > > find the project site, then hope they have docs in a separate
> download,
> > > > or (b) we end up with foo+1 packages, one extra for any package that
> has
> > > > documentation. Neither are particularly good solutions; Debian has
> done
> > > > the latter and it results in a huge number of packages for little
> gain.
> > >
> > > The Python team mostly focuses on providing packages for dependencies
> of
> > > other Gentoo packages, not direct Python development. We do not have
> > > the manpower to go above that.
> > >
> > > --
> > > Best regards,
> > > Michał Górny
> >
> > Ah, well that at least explains why you're not interested in it.
> > Dependency management alone can be tough; I've not noticed any Python
> > issues, so it seems like you guys do well. :) If you don't mind me
> > asking, what would it take to solve the USE="doc" issue to the Python
> > team's standard? I have some personal interest in Python and wouldn't
> > mind adding 'doc' support for Python packages that users request docs
> > for.
> >
> > Maybe others are willing to join me on this. Is that something we can
> > make happen without getting in anyone's hair?
> >
>
> For a start, it'd be nice to figure all the stuff out in detail,
> and document it -- when USEDEP is needed, not needed, when we need
> something else (like the plugin case). Once that is done, it's just
> a matter of checking and fixing existing packages, and being patient
> with devs doing the same mistakes again ;-).
>
> --
> Best regards,
> Michał Górny
>

[-- Attachment #2: Type: text/html, Size: 4021 bytes --]

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [gentoo-dev] Should Sphinx really depends on PYTHON_COMPAT/PYTHON_USEDEP for `dev-python/*` ebuilds?
  2017-05-18  6:23           ` Alex Turbov
@ 2017-05-18  6:46             ` Michał Górny
  0 siblings, 0 replies; 15+ messages in thread
From: Michał Górny @ 2017-05-18  6:46 UTC (permalink / raw
  To: gentoo-dev, Alex Turbov

Dnia 18 maja 2017 08:23:26 CEST, Alex Turbov <i.zaufi@gmail.com> napisał(a):
>As for me I'm doing few Python projects and as I said before I prefer
>to
>have (real) offline docs, cuz often visit places far from
>"civilization"
>and where 150Kib/s considered as pretty fast Internet connection. Also
>I'm
>very patient on keeping my Gentoo system under control and minimized
>(eliminating unnecessary dependencies and files). I could help with
>adding
>patches and bug reports for packages I use.

Please use pull requests. And focus on easy cases first. For the plugin case, I need to create the necessary logic in the eclass.

>
>On Thu, May 18, 2017 at 12:10 PM, Michał Górny <mgorny@gentoo.org>
>wrote:
>
>> On śro, 2017-05-17 at 21:44 -0700, Daniel Campbell wrote:
>> > On Sat, May 13, 2017 at 09:32:46AM +0200, Michał Górny wrote:
>> > > On pią, 2017-05-12 at 17:42 -0700, Daniel Campbell wrote:
>> > > > On 05/11/2017 12:51 AM, Michał Górny wrote:
>> > > > > In fact, I'm personally leaning towards not building docs at
>all
>> > > > > in ebuilds. It's practically a wasted effort since most of
>the time
>> > > > > users read docs online anyway.
>> > > >
>> > > > I believe that's a little myopic; a user (or even developer)
>may not
>> > > > have Internet access all the time, or may not have it in their
>> primary
>> > > > development environment. Having a copy of the docs locally (the
>> entire
>> > > > point of USE="doc") is super valuable to have when you're away
>from
>> the
>> > > > network. I'm sure I'm not alone as one of the people who uses
>the
>> flag
>> > > > and appreciates the work that goes into making sure said flag
>works.
>> > > >
>> > > > Sure, we could yank out every single USE="doc", but then we
>lose a
>> nice
>> > > > feature of the tree and users are back to either (a) trawling
>the
>> Web to
>> > > > find the project site, then hope they have docs in a separate
>> download,
>> > > > or (b) we end up with foo+1 packages, one extra for any package
>that
>> has
>> > > > documentation. Neither are particularly good solutions; Debian
>has
>> done
>> > > > the latter and it results in a huge number of packages for
>little
>> gain.
>> > >
>> > > The Python team mostly focuses on providing packages for
>dependencies
>> of
>> > > other Gentoo packages, not direct Python development. We do not
>have
>> > > the manpower to go above that.
>> > >
>> > > --
>> > > Best regards,
>> > > Michał Górny
>> >
>> > Ah, well that at least explains why you're not interested in it.
>> > Dependency management alone can be tough; I've not noticed any
>Python
>> > issues, so it seems like you guys do well. :) If you don't mind me
>> > asking, what would it take to solve the USE="doc" issue to the
>Python
>> > team's standard? I have some personal interest in Python and
>wouldn't
>> > mind adding 'doc' support for Python packages that users request
>docs
>> > for.
>> >
>> > Maybe others are willing to join me on this. Is that something we
>can
>> > make happen without getting in anyone's hair?
>> >
>>
>> For a start, it'd be nice to figure all the stuff out in detail,
>> and document it -- when USEDEP is needed, not needed, when we need
>> something else (like the plugin case). Once that is done, it's just
>> a matter of checking and fixing existing packages, and being patient
>> with devs doing the same mistakes again ;-).
>>
>> --
>> Best regards,
>> Michał Górny
>>


-- 
Best regards,
Michał Górny (by phone)


^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [gentoo-dev] Should Sphinx really depends on PYTHON_COMPAT/PYTHON_USEDEP for `dev-python/*` ebuilds?
  2017-05-12 18:32 ` Michał Górny
@ 2017-05-18 22:07   ` Daniel Campbell
  2017-05-18 22:30     ` Michał Górny
  0 siblings, 1 reply; 15+ messages in thread
From: Daniel Campbell @ 2017-05-18 22:07 UTC (permalink / raw
  To: gentoo-dev

[-- Attachment #1: Type: text/plain, Size: 3761 bytes --]

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?

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.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [gentoo-dev] Should Sphinx really depends on PYTHON_COMPAT/PYTHON_USEDEP for `dev-python/*` ebuilds?
  2017-05-18 22:07   ` Daniel Campbell
@ 2017-05-18 22:30     ` Michał Górny
  2017-05-19  1:18       ` Daniel Campbell
  0 siblings, 1 reply; 15+ messages in thread
From: Michał Górny @ 2017-05-18 22:30 UTC (permalink / raw
  To: gentoo-dev

[-- Attachment #1: Type: text/plain, Size: 4578 bytes --]

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

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 963 bytes --]

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: [gentoo-dev] Should Sphinx really depends on PYTHON_COMPAT/PYTHON_USEDEP for `dev-python/*` ebuilds?
  2017-05-18 22:30     ` Michał Górny
@ 2017-05-19  1:18       ` Daniel Campbell
  0 siblings, 0 replies; 15+ messages in thread
From: Daniel Campbell @ 2017-05-19  1:18 UTC (permalink / raw
  To: gentoo-dev


[-- Attachment #1.1: Type: text/plain, Size: 4908 bytes --]

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


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 15+ messages in thread

end of thread, other threads:[~2017-05-19  1:18 UTC | newest]

Thread overview: 15+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2017-05-11  4:47 [gentoo-dev] Should Sphinx really depends on PYTHON_COMPAT/PYTHON_USEDEP for `dev-python/*` ebuilds? Alex Turbov
2017-05-11  7:51 ` Michał Górny
2017-05-12  6:20   ` Alex Turbov
2017-05-12 17:18     ` Michał Górny
2017-05-13  0:42   ` Daniel Campbell
2017-05-13  1:28     ` Dale
2017-05-13  7:32     ` Michał Górny
2017-05-18  4:44       ` Daniel Campbell
2017-05-18  5:10         ` Michał Górny
2017-05-18  6:23           ` Alex Turbov
2017-05-18  6:46             ` Michał Górny
2017-05-12 18:32 ` Michał Górny
2017-05-18 22:07   ` Daniel Campbell
2017-05-18 22:30     ` Michał Górny
2017-05-19  1:18       ` Daniel Campbell

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox