Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 702236 - sys-apps/pkgcore-0.10.8 : src_install(): ModuleNotFoundError: No module named 'setuptools'
Summary: sys-apps/pkgcore-0.10.8 : src_install(): ModuleNotFoundError: No module named...
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Tim Harder
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-12-07 10:22 UTC by Joakim Tjernlund
Modified: 2019-12-07 20:31 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
sys-apps:pkgcore-0.10.8:20191207-104501.log (sys-apps:pkgcore-0.10.8:20191207-104501.log,141.37 KB, text/plain)
2019-12-07 10:53 UTC, Jeroen Roovers (RETIRED)
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Joakim Tjernlund 2019-12-07 10:22:16 UTC
...
writing EAPI 7 src_configure phase lib: '/var/tmp/portage/sys-apps/pkgcore-9999/image/_python3.6/usr/lib/pkgcore/ebd/.generated/libs/7/src_configure'
writing EAPI 7 pkg_pretend phase lib: '/var/tmp/portage/sys-apps/pkgcore-9999/image/_python3.6/usr/lib/pkgcore/ebd/.generated/libs/7/pkg_pretend'
 * python3_7: running distutils-r1_run_phase python_install_all
python3.7 setup.py install_docs --docdir=/var/tmp/portage/sys-apps/pkgcore-9999/image/usr/share/doc/pkgcore-9999 --mandir=/var/tmp/portage/sys-apps/pkgcore-9999/image/usr/share/man
Traceback (most recent call last):
  File "setup.py", line 13, in <module>
    from setuptools import setup
ModuleNotFoundError: No module named 'setuptools'
 * ERROR: sys-apps/pkgcore-9999::gentoo failed (install phase):
 *   (no error message)
 * 
 * Call stack:
 *     ebuild.sh, line  125:  Called src_install
 *   environment, line 3377:  Called distutils-r1_src_install
 *   environment, line 1109:  Called _distutils-r1_run_common_phase 'python_install_all'
 *   environment, line  350:  Called multibuild_foreach_variant 'distutils-r1_run_phase' 'python_install_all'
 *   environment, line 2277:  Called _multibuild_run 'distutils-r1_run_phase' 'python_install_all'
 *   environment, line 2275:  Called distutils-r1_run_phase 'python_install_all'
 *   environment, line 1073:  Called python_install_all
 *   environment, line 3074:  Called esetup.py 'install_docs' '--docdir=/var/tmp/portage/sys-apps/pkgcore-9999/image/usr/share/doc/pkgcore-9999' '--mandir=/var/tmp/portage/sys-apps/pkgcore-9999/image/usr/share/man'
 *   environment, line 1457:  Called die
 * The specific snippet of code:
 *       "${@}" || die "${die_args[@]}";

I don't have python7 installed
Comment 1 Joakim Tjernlund 2019-12-07 10:23:56 UTC
I meant that I HAVE python7 installed, sorry
Comment 2 Jeroen Roovers (RETIRED) gentoo-dev 2019-12-07 10:29:51 UTC
(In reply to Joakim Tjernlund from comment #1)
> I meant that I HAVE python7 installed, sorry

What is python7?
Comment 3 Tim Harder gentoo-dev 2019-12-07 10:32:16 UTC
Are you running against a copy of the gentoo repo that has the most recent changes to pkgcore? In particular compare python_check_deps() to what's in the upstream tree [1].

[1]: https://gitweb.gentoo.org/repo/gentoo.git/tree/sys-apps/pkgcore/pkgcore-9999.ebuild#n41
Comment 4 Tim Harder gentoo-dev 2019-12-07 10:32:48 UTC
(In reply to Jeroen Roovers from comment #2)
> (In reply to Joakim Tjernlund from comment #1)
> > I meant that I HAVE python7 installed, sorry
> 
> What is python7?

I assume he means python3_7.
Comment 5 Tim Harder gentoo-dev 2019-12-07 10:36:26 UTC
I would also question if you even have setuptools installed for python3_7 as it appears you do not.
Comment 6 Jeroen Roovers (RETIRED) gentoo-dev 2019-12-07 10:53:30 UTC
Created attachment 598830 [details]
sys-apps:pkgcore-0.10.8:20191207-104501.log

This also affects 0.10.8.
Comment 7 Tim Harder gentoo-dev 2019-12-07 11:23:46 UTC

*** This bug has been marked as a duplicate of bug 701960 ***
Comment 8 Jeroen Roovers (RETIRED) gentoo-dev 2019-12-07 11:27:50 UTC
(In reply to Tim Harder from comment #7)
> 
> *** This bug has been marked as a duplicate of bug 701960 ***

How is this a duplicate when the original was ostensibly resolved as fixed two days ago while this bug has only been reported just now?
Comment 9 Tim Harder gentoo-dev 2019-12-07 11:33:04 UTC
(In reply to Jeroen Roovers from comment #8)
> (In reply to Tim Harder from comment #7)
> > 
> > *** This bug has been marked as a duplicate of bug 701960 ***
> 
> How is this a duplicate when the original was ostensibly resolved as fixed
> two days ago while this bug has only been reported just now?

AFAICS, it's the same underlying bug with python eclass sphinx python3_8 issues.
Comment 10 Tim Harder gentoo-dev 2019-12-07 11:34:47 UTC
(In reply to Tim Harder from comment #9)
> (In reply to Jeroen Roovers from comment #8)
> > (In reply to Tim Harder from comment #7)
> > > 
> > > *** This bug has been marked as a duplicate of bug 701960 ***
> > 
> > How is this a duplicate when the original was ostensibly resolved as fixed
> > two days ago while this bug has only been reported just now?
> 
> AFAICS, it's the same underlying bug with python eclass sphinx python3_8
> issues.

i.e. it wasn't actually *fixed* two days ago and this time I'll let mgorny or someone who actually is more knowledgeable about the eclasses fix it.
Comment 11 Jeroen Roovers (RETIRED) gentoo-dev 2019-12-07 12:02:12 UTC
(In reply to Tim Harder from comment #10)
> i.e. it wasn't actually *fixed* two days ago and this time I'll let mgorny
> or someone who actually is more knowledgeable about the eclasses fix it.

Ah, you reopened it. Thanks.
Comment 12 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2019-12-07 14:54:04 UTC
This is actually a different bug.  It happens because the ebuild is building docs with USE=doc only but calling install unconditionally.

@radhermit, is this really expected?  Could you elaborate on what is the goal here?
Comment 13 Jouni Kosonen 2019-12-07 19:55:52 UTC
Isn't the problem here and in bug 701960 that python_install_all gets run for versions in PYTHON_COMPAT but not in PYTHON_TARGETS?

The posted log is from a different run than the snippet, since it has this:
> python3_8: running distutils-r1_run_phase python_install_all
Comment 14 Tim Harder gentoo-dev 2019-12-07 20:06:47 UTC
(In reply to Jouni Kosonen from comment #13)
> Isn't the problem here and in bug 701960 that python_install_all gets run
> for versions in PYTHON_COMPAT but not in PYTHON_TARGETS?
> 
> The posted log is from a different run than the snippet, since it has this:
> > python3_8: running distutils-r1_run_phase python_install_all

Yes, that's why I thought it was related to bug #701960 as that's the same underlying issue (although in #710960 it was python_compile_all getting called).
Comment 15 Tim Harder gentoo-dev 2019-12-07 20:16:16 UTC
(In reply to Michał Górny from comment #12)
> This is actually a different bug.  It happens because the ebuild is building
> docs with USE=doc only but calling install unconditionally.

I still think it is a related underlying issue. Why does the eclass select a python target to use for both python_compile_all and python_install_all that's not actually enabled for the build?

> @radhermit, is this really expected?  Could you elaborate on what is the
> goal here?

The goal is to install what docs having been prebuilt or are available after building without having to conditionalize. If none exist (live ebuilds with the doc USE flag disabled) it just gets ignored. As far as I can tell, it should work properly if the eclass uses the same, enabled python impl to run both python_compile_all and python_install_all, which imo it should.
Comment 16 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2019-12-07 20:21:14 UTC
(In reply to Tim Harder from comment #15)
> (In reply to Michał Górny from comment #12)
> > This is actually a different bug.  It happens because the ebuild is building
> > docs with USE=doc only but calling install unconditionally.
> 
> I still think it is a related underlying issue. Why does the eclass select a
> python target to use for both python_compile_all and python_install_all
> that's not actually enabled for the build?

Because you may not have Sphinx and other deps available with the same targets.  For example, if you build pkgcore with py3.8 only, you'd have to use sphinx for py3.7 or older.

I'll fix it.
Comment 17 Larry the Git Cow gentoo-dev 2019-12-07 20:31:40 UTC
The bug has been closed via the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=b83196eff9ea2a659440e704feac5a82cd6c327f

commit b83196eff9ea2a659440e704feac5a82cd6c327f
Author:     Michał Górny <mgorny@gentoo.org>
AuthorDate: 2019-12-07 20:24:55 +0000
Commit:     Michał Górny <mgorny@gentoo.org>
CommitDate: 2019-12-07 20:31:31 +0000

    sys-apps/pkgcore: Require setuptools for doc install too
    
    Closes: https://bugs.gentoo.org/702236
    Signed-off-by: Michał Górny <mgorny@gentoo.org>

 sys-apps/pkgcore/pkgcore-0.10.8.ebuild | 5 ++++-
 sys-apps/pkgcore/pkgcore-9999.ebuild   | 5 ++++-
 2 files changed, 8 insertions(+), 2 deletions(-)