Apart from the commandline tools gentoolkit also contains a useful python module. When you write a tool that uses this module you have to do something like: import sys sys.path.append("/usr/lib/gentoolkit/pym") import gentoolkit because the modules are installed to a non-standard location. It looks like it mimics portage here (that also has a /pym/ directory). As far as I know portage uses this layout because it must keep functioning if the python version changes underneath it. Gentoolkit has no such requirement, so I think it would make more sense if it installed to site-packages like an "ordinary" python package. Reproducible: Always Steps to Reproduce: 1. emerge gentoolkit 2. python -c 'import gentoolkit' Actual Results: ImportError is raised. Expected Results: Imported gentoolkit. Portage 2.0.51.16 (hardened/x86/2.6, gcc-3.4.3-20050110, glibc-2.3.4.20050125-r0, 2.6.10-gentoo-r7-m2 i686) ================================================================= System uname: 2.6.10-gentoo-r7-m2 i686 AMD Athlon(tm) XP 2600+ Gentoo Base System version 1.6.9 Python: dev-lang/python-2.4-r2 [2.4 (#1, Feb 22 2005, 15:02:34)] dev-lang/python: 2.4-r2 sys-devel/autoconf: 2.59-r6, 2.13 sys-devel/automake: 1.7.9-r1, 1.8.5-r3, 1.5, 1.4_p6, 1.6.3, 1.9.4 sys-devel/binutils: 2.15.92.0.2-r3 sys-devel/libtool: 1.5.10-r4 virtual/os-headers: 2.6.8.1-r2 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CFLAGS="-O2 -march=athlon-xp -pipe -fomit-frame-pointer -fweb -frename-registers" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.4/env /usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -march=athlon-xp -pipe -fomit-frame-pointer -fweb -frename-registers" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs autoconfig candy ccache confcache distlocks noauto prelink sandbox test userpriv usersandbox verify-rdepend" GENTOO_MIRRORS="http://ftp.easynet.nl/mirror/gentoo/ http://www.gigaload.org/gentoo.org/" LANG="en_US.UTF-8" MAKEOPTS="-j2" PKGDIR="/usr/portage//packages/x86/" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage/" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.nl.gentoo.org/gentoo-portage" USE="x86 3dnow 3dnowex X alsa ansi bzip2 cdr crypt dlloader emacs faad fbcon flac gnome gtk2 javascript jit jpeg kdeenablefinal libcaca maildir md5sum mmx mmx2 mng mozdevelop mozsvg mpeg ncurses nethack network nls no-old-linux nptl nptlonly oggvorbis opengl pam pic pie png python qemu-fast quicktime readline rtc sdl softmmu spell sse ssl svg symlink tetex truetype truetype-fonts unicode userlocales xml2 xv zlib" Unset: ASFLAGS, CBUILD, CTARGET, LC_ALL, LDFLAGS
Created attachment 51955 [details, diff] extremely icky ebuild patch to use site-packages This applies to gentoolkit-0.2.0.ebuild. It just moves the files in pkg_install after the Makefile installed into /usr/lib/gentoolkit/pym/ as usual. This is sufficient to see if everything works. If this change is accepted, one of the following should probably be done: - modify the Makefiles in the gentoolkit tarball to install to site-packages - modify the package to use python's distutils instead of Makefiles. If it is decided this is a good idea I'll try to write patches for one or both approaches.
Created attachment 144225 [details, diff] gentoolkit_to_site_packages.diff Patch to change the Makefiles and the scripts to use site-packages instead of pym. Ebuild patch forthcoming. TODO: app-portage/kuroo reverse depends on gentoolkit, may need some coordination.
Created attachment 144252 [details, diff] gentoolkit-0.2.4_rc2.ebuild-site-packages.patch Takes advantage of the site-packages change.
*** Bug 139606 has been marked as a duplicate of this bug. ***
Created attachment 144681 [details, diff] gentoolkit_portagepath.patch etcat and gensync were the only packages that didn't have error handling wrapping the import portage. I think both of those scripts are deprecated anyway, but handling the import can only be a harmless improvement. This patch implements that.
Bug 139606 was originally targeted especially at prefix users. (I guess because the ordinary default of usr/lib/XXX/pym would not necessarily reside at / for them.) These patches should resolve this problem for prefixers. Please test.
That won't work any better for prefix, since it still hardcodes non-prefix paths.
(In reply to comment #7) > That won't work any better for prefix, since it still hardcodes non-prefix > paths. It only uses those hardcoded paths if portage hasn't added the correct path to PYTHONPATH in the first place, but your point is well made. I don't really want to inherit multilib in the ebuild just to get_libdir, because I don't think the ebuild should have to make mention of any lib path at all. Unfortunately, gentoolkit is installed by a Makefile that does have to know where the python site-packages are supposed to go. I suppose marienz' original comment #1 that gentoolkit should use python distutils is right. I'll get back to this later and see what I can do.
(In reply to comment #8) > I don't really want to inherit multilib in the ebuild just to get_libdir, > because I don't think the ebuild should have to make mention of any lib path > at all. > > Unfortunately, gentoolkit is installed by a Makefile that does have to know > where the python site-packages are supposed to go. I suppose marienz' > original comment #1 that gentoolkit should use python distutils is right. Funnily enough distutils.eclass inherits multilib just to get get_libdir...
djanderson's modular rewrite of equery and gentoolkit was committed into trunk with rev 589.
gentoolkit-0.3.0_rc5 released. Thanks to djanderson for the hard work on equery and gentoolkit.
