Summary: | dev-python/pylint[doc]: building docs requires pylint to be installed first | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Andrey Grozin <grozin> |
Component: | [OLD] Development | Assignee: | Alex Brandt (RETIRED) <alunduil> |
Status: | RESOLVED FIXED | ||
Severity: | minor | CC: | alunduil |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Andrey Grozin
2014-08-08 14:50:05 UTC
dev-python/pylint $ USE=doc ebuild pylint-1.3.0.ebuild install
~/cvsPortage/gentoo-x86/dev-python/pylint $ ls /mnt/gen2/TmpDir/portage/dev-python/pylint-1.3.0/work/pylint-1.3.0/doc/_build/
doctrees singlehtml
* python2_7: running distutils-r1_run_phase python_install_all
>>> Completed installing pylint-1.3.0 into /mnt/gen2/TmpDir/portage/dev-python/pylint-1.3.0/image/
~/cvsPortage/gentoo-x86/dev-python/pylint $ ls /mnt/gen2/TmpDir/portage/dev-python/pylint-1.3.0/image/usr/share/doc/pylint-1.3.0/html/
_images index.html _static
This problem has been solved by re-emerging pygments, sorry for the noise. But after re-emerging pygments and sphinx I'm having another problem: make -j1 -C doc singlehtml make: Entering directory '/var/tmp/portage/dev-python/pylint-1.3.0/work/pylint-1.3.0/doc' sphinx-build -b singlehtml -d _build/doctrees . _build/singlehtml Making output directory... Running Sphinx v1.2.2 Exception occurred: File "conf.py", line 51, in <module> from pylint.__pkginfo__ import version ImportError: No module named pylint.__pkginfo__ The full traceback has been saved in /var/tmp/portage/dev-python/pylint-1.3.0/temp/sphinx-err-_zupu1.log, if you want to report the issue to the developers. Please also report this if it was a user error, so that a better error message can be provided next time. A bug report can be filed in the tracker at <https://bitbucket.org/birkenfeld/sphinx/issues/>. Thanks! Makefile:51: recipe for target 'singlehtml' failed make: *** [singlehtml] Error 1 make: Leaving directory '/var/tmp/portage/dev-python/pylint-1.3.0/work/pylint-1.3.0/doc' * ERROR: dev-python/pylint-1.3.0::gentoo failed (prepare phase): /var/tmp/portage/dev-python/pylint-1.3.0/temp/sphinx-err-_zupu1.log: -------------------------------------------------------------------- # Sphinx version: 1.2.2 # Python version: 3.2.5 # Docutils version: 0.12 release # Jinja2 version: 2.6 # Loaded extensions: Traceback (most recent call last): File "/usr/lib/python3.2/site-packages/sphinx/cmdline.py", line 253, in main warningiserror, tags, verbosity, parallel) File "/usr/lib/python3.2/site-packages/sphinx/application.py", line 107, in __init__ confoverrides or {}, self.tags) File "/usr/lib/python3.2/site-packages/sphinx/config.py", line 229, in __init__ execfile_(filename, config) File "/usr/lib/python3.2/site-packages/sphinx/util/pycompat.py", line 105, in execfile_ exec(code, _globals) File "conf.py", line 51, in <module> from pylint.__pkginfo__ import version ImportError: No module named pylint.__pkginfo__ -------------------------------------------------------------------- ~/cvsPortage/gentoo-x86/dev-python/pylint $ USE=doc ebuild pylint-1.3.0.ebuild clean install
yields
* python2_7: running distutils-r1_run_phase python_install_all
>>> Completed installing pylint-1.3.0 into /mnt/gen2/TmpDir/portage/dev-python/pylint-1.3.0/image/
ecompressdir: bzip2 -9 /usr/share/doc
ecompressdir: bzip2 -9 /usr/share/man
~/cvsPortage/gentoo-x86/dev-python/pylint $ python -c "from pylint.__pkginfo__ import version"
~/cvsPortage/gentoo-x86/dev-python/pylint $ python3.3 -c "from pylint.__pkginfo__ import version"
~/cvsPortage/gentoo-x86/dev-python/pylint $ python3.4 -c "from pylint.__pkginfo__ import version"
all return blank == success
This problem has been solved by re-emerging pygments,
You might try re-emerging pylint
I'm seeing this issue even after a fresh install of pygments. Looks like the same error as reported by Andrey. This looks like it is due to pylint not being installed when trying to install pylint with documentation. Can we find a way to build the pylint egg and put it in the path before building the documentation? Possibly but is it the desired solution. In other ebuilds, a msg is simply put to user informing that the package need be installed to build the docs. It's the path of least resistance, a compromise I'd vote that just printing a message is unacceptable because it adds more load to the user to accomplish what portage should be doing for them (installing package with docs). I'd also think that pylint might do with a patch to make this requirement moot but haven't looked at it to see how feasible that would be. Regardless, we seem to (in the occasional corner case) require an install of a python package that isn't live for various reasons and we should probably solve this generically. (In reply to Alex Brandt from comment #6) > I'd vote that just printing a message is unacceptable because it adds more > load to the user to accomplish what portage should be doing for them > (installing package with docs). > yes this is a 'reasonable' assessment with which I agree. It's merely a form or resolution that has precedent however it doesn't make it a 'good' one. > I'd also think that pylint might do with a patch to make this requirement > moot but haven't looked at it to see how feasible that would be. > > Regardless, we seem to (in the occasional corner case) require an install of > a python package that isn't live for various reasons and we should probably > solve this generically. Agreed. feel free to proceed. (In reply to Ian Delaney from comment #7) > yes this is a 'reasonable' assessment with which I agree. It's merely a form > or resolution that has precedent however it doesn't make it a 'good' one. Just to clarify, you're saying my proposal is agreeable but bad? > Agreed. feel free to proceed. If only I had the time. I was simply adding rhetoric to the already smoking ember. (In reply to Alex Brandt from comment #8) > (In reply to Ian Delaney from comment #7) > > yes this is a 'reasonable' assessment with which I agree. It's merely a form > > or resolution that has precedent however it doesn't make it a 'good' one. > > Just to clarify, you're saying my proposal is agreeable but bad? I read it as saying that the existing ewarn message "solution" is not a good one. It's just what we have been doing thus far to work around the problem. Ian: Do you have some examples of ebuilds which output such a message? I would like to take a look. (In reply to Mike Gilbert from comment #9) > > Ian: Do you have some examples of ebuilds which output such a message? I > would like to take a look. So you can dissect them, put them under scrutiny and declare them as improper ebuild writing? I might be guilty of drawing too long a bow here. I cannot remember this for a doc build but certainly for tests. i.e. emerge package to run testsuite. logilab-common did this I think, or the reverse I am not sure. My memory tells me that 1. months ago on looking at the first disaster of a tarball for a bump of ipython, it required the package to be installed for a doc build. While the next version of a tarball for that bumped version did that 'properly', and hence took away the need for a generic fix, Arfrever mentioned he knew how to do it, or at least that it could be done. 2. I recall there was a package where the (stupid) testsuite wouldn't run until it was installed. While trying to find a way to avoid installing the package to run tests, I couldn't. I recall Arfrever advising to just settle on elog msg to user to "if you want to run the testsuite, emerge the package then re-emerge with FEATURES=test". Since no-one clearly had an alternate proper fix and everyone was determined for second best, who am I to argue? 3. No I DO NOT remember what the package was. It was at least 6 months ago and I'll tell you when I have a photographic memory. I might also be remembering incorrectly if only ever so slightly. 4. IUSE test and doc are rather similar; global use flags often used and pertinent in pythonic packages. For all the packages I have done I haven't yet learned a 'proper fix' for install package first run USE=test or doc second, proving it a corner case and fundamentally bad or wrong authorship by maintainers. I have just gleaned that it almost certainly can be done. distutils_install_for_testing was written as an attempt to fix this blunder for testsuites, mainly for logilab-common itself I think, but on last I saw or heard it is close to unusable for a number of distinct reasons. (In reply to Alex Brandt from comment #8) > Just to clarify, you're saying my proposal is agreeable but bad? > When I was commenting as a form or resolution that has precedent, it was "a msg is simply put to user informing that the package need be installed", "It's the path of least resistance, a compromise". Assessing this as bad is taking it to another level. Your proposal "that pylint might do with a patch to make this requirement moot" is hardly what I would call bad. What I want to know is how you managed to seemingly assign the assessment of one onto the other. To put a msg via elog is light weight and nothing more than a workaround. To fix it is the better path, but sigh "If only I had the time." I dug into this and found that it actually was missing the PYTHONPATH for doc building. I have a working version in my overlay that I'll commit soon that resolves this. Committed fix to tree. Added PYTHONPATH="${S}" to documentation build. |