Re: [gentoo-dev] Should Sphinx really depends on PYTHON_COMPAT/PYTHON_USEDEP for `dev-python/*` ebuilds?

[Michał Górny]

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

Re: [gentoo-dev] Should Sphinx really depends on PYTHON_COMPAT/PYTHON_USEDEP for `dev-python/*` ebuilds?

[Daniel Campbell]

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.


signature.asc
Description: Digital signature

Re: [gentoo-dev] Should Sphinx really depends on PYTHON_COMPAT/PYTHON_USEDEP for `dev-python/*` ebuilds?

[Michał Górny]

Dnia 18 maja 2017 08:23:26 CEST, Alex Turbov  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 
>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)

Re: [gentoo-dev] Should Sphinx really depends on PYTHON_COMPAT/PYTHON_USEDEP for `dev-python/*` ebuilds?

[Alex Turbov]

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

Re: [gentoo-dev] Should Sphinx really depends on PYTHON_COMPAT/PYTHON_USEDEP for `dev-python/*` ebuilds?

[Michał Górny]

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


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] Should Sphinx really depends on PYTHON_COMPAT/PYTHON_USEDEP for `dev-python/*` ebuilds?

[Daniel Campbell]

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


signature.asc
Description: Digital signature

Re: [gentoo-dev] Should Sphinx really depends on PYTHON_COMPAT/PYTHON_USEDEP for `dev-python/*` ebuilds?

[Michał Górny]

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


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] Should Sphinx really depends on PYTHON_COMPAT/PYTHON_USEDEP for `dev-python/*` ebuilds?

[Dale]

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

:-)  :-) 

Re: [gentoo-dev] Should Sphinx really depends on PYTHON_COMPAT/PYTHON_USEDEP for `dev-python/*` ebuilds?

[Daniel Campbell]

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



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Should Sphinx really depends on PYTHON_COMPAT/PYTHON_USEDEP for `dev-python/*` ebuilds?

[Michał Górny]

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


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] Should Sphinx really depends on PYTHON_COMPAT/PYTHON_USEDEP for `dev-python/*` ebuilds?

[Michał Górny]

On pią, 2017-05-12 at 13:20 +0700, Alex Turbov wrote:
> On Thu, May 11, 2017 at 2:51 PM, Michał Górny  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


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] Should Sphinx really depends on PYTHON_COMPAT/PYTHON_USEDEP for `dev-python/*` ebuilds?

[Alex Turbov]

On Thu, May 11, 2017 at 2:51 PM, Michał Górny  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
>

Re: [gentoo-dev] Should Sphinx really depends on PYTHON_COMPAT/PYTHON_USEDEP for `dev-python/*` ebuilds?

[Michał Górny]

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


signature.asc
Description: This is a digitally signed message part