>>> Install youtube-dl-2012.12.11 into /Library/Gentoo/var/tmp/portage/net-misc/youtube-dl-2012.12.11/image/ category net-misc ------------------------------------------------------- You should not use ${EPREFIX} with helpers. --> /Library/Gentoo/usr/lib/python2.7/site-packages/ ------------------------------------------------------- * ERROR: net-misc/youtube-dl-2012.12.11 failed (install phase): * (no error message) * * Call stack: * ebuild.sh, line 93: Called call-ebuildshell 'src_install' * environment, line 260: Called src_install * environment, line 1060: Called python_domodule 'youtube_dl' * environment, line 858: Called die * The specific snippet of code: * doins -r "${@}" || die; * Problem is most likely in the fuzzyness of PYTHON_SITEDIR, which includes EPREFIX. python_moduleroot can be given, but it is not exactly clear with or without EPREFIX. Since it documents a prepending of D, but since all "helpers" usually handle EPREFIX, it appears most natural EPREFIX should not be given there explicitly. That is, it should prepend ED. Not sure, consistency here is more important, and I lack the overview. However, for said scenario the following patch would do: diff -u -r1.9 python-utils-r1.eclass --- python-utils-r1.eclass 20 Dec 2012 23:35:17 -0000 1.9 +++ python-utils-r1.eclass 26 Dec 2012 15:37:58 -0000 @@ -515,7 +515,7 @@ d=${python_moduleroot} else # relative to site-packages - local PYTHON_SITEDIR=${PYTHON_SITEDIR} + local PYTHON_SITEDIR=${PYTHON_SITEDIR#${EPREFIX}} [[ ${PYTHON_SITEDIR} ]] || python_export PYTHON_SITEDIR d=${PYTHON_SITEDIR}/${python_moduleroot} @@ -526,7 +526,7 @@ insinto "${d}" doins -r "${@}" || die - python_optimize "${D}/${d}" + python_optimize "${ED}/${d}" } _PYTHON_UTILS_R1=1
That raises the question of whether $(python_get_sitedir) should return the path with or without EPREFIX. Which one do you believe is more useful / easier for our users?
I would vote for having it not include EPREFIX. I think it is cleaner to add it where necessary than to remove it using shell parameter replacement.
(In reply to comment #2) > I would vote for having it not include EPREFIX. I think it is cleaner to add > it where necessary than to remove it using shell parameter replacement. Can you tell me what Python internals return? I'm not sure what would be the most relevant value; maybe sys.prefix? I'd honestly keep it the way it is now. The only use for EPREFIX-less variant I see is using doins which is basically done in -r1 eclasses through python_domodule().
(In reply to comment #3) > Can you tell me what Python internals return? I'm not sure what would be the > most relevant value; maybe sys.prefix? Have a look at distutils.sysconfig.get_python_lib(). It basically returns this: os.path.join(sys.prefix, "lib", "python" + python_get_version(), "site-packages") I'm guessing that EPREFIX would be included in sys.prefix, but I don't have a prefix system to confirm.
the old python eclasses did not return EPREFIX Python itself of course returns EPREFIX, as it does return /usr for you.
(In reply to comment #5) > the old python eclasses did not return EPREFIX I don't think that keeping unnecessarily compliant with the old eclass is really important here. > Python itself of course returns EPREFIX, as it does return /usr for you. Then I'd stick with that. Since distutils does Prefix itself by default, I think our functions should follow that. Additionally, changing the current value of PYTHON_SITEDIR would effectively break some of the existing -r1 ebuilds.
Created attachment 333752 [details, diff] Proposed patch @Fabian, please test the attached patch. It addresses installing scripts & modules to explicitly specified paths as well.
it works for youtube-dl
Committed then. The topic of PYTHON_SITEDIR is still open, though I'd rather not change it since it's used in a few places already.
