Created attachment 333508 [details] patch to dev-python/pygobject-3.4.2-r1 With Python 3.3 packages installed by dev-python/pygobject-3.4.2-r1 are byte-compiled as per Python 2: $ qlist dev-python/pygobject-3.4.2-r1 | grep pyc /usr/lib64/python3.3/site-packages/gi/repository/__init__.pyc /usr/lib64/python3.3/site-packages/gi/overrides/GLib.pyc /usr/lib64/python3.3/site-packages/gi/overrides/Gtk.pyc /usr/lib64/python3.3/site-packages/gi/overrides/Gdk.pyc /usr/lib64/python3.3/site-packages/gi/overrides/Gio.pyc /usr/lib64/python3.3/site-packages/gi/overrides/GIMarshallingTests.pyc /usr/lib64/python3.3/site-packages/gi/overrides/Pango.pyc /usr/lib64/python3.3/site-packages/gi/overrides/keysyms.pyc /usr/lib64/python3.3/site-packages/gi/overrides/__init__.pyc /usr/lib64/python3.3/site-packages/gi/_glib/__init__.pyc /usr/lib64/python3.3/site-packages/gi/_glib/option.pyc /usr/lib64/python3.3/site-packages/gi/_gobject/__init__.pyc /usr/lib64/python3.3/site-packages/gi/_gobject/constants.pyc /usr/lib64/python3.3/site-packages/gi/_gobject/propertyhelper.pyc /usr/lib64/python3.3/site-packages/gi/_gobject/signalhelper.pyc /usr/lib64/python3.3/site-packages/gi/__init__.pyc /usr/lib64/python3.3/site-packages/gi/types.pyc /usr/lib64/python3.3/site-packages/gi/module.pyc /usr/lib64/python3.3/site-packages/gi/importer.pyc /usr/lib64/python3.3/site-packages/gi/pygtkcompat.pyc /usr/lib64/python2.7/site-packages/gi/repository/__init__.pyc /usr/lib64/python2.7/site-packages/gi/overrides/GLib.pyc /usr/lib64/python2.7/site-packages/gi/overrides/Gtk.pyc /usr/lib64/python2.7/site-packages/gi/overrides/Gdk.pyc /usr/lib64/python2.7/site-packages/gi/overrides/Gio.pyc /usr/lib64/python2.7/site-packages/gi/overrides/GIMarshallingTests.pyc /usr/lib64/python2.7/site-packages/gi/overrides/Pango.pyc /usr/lib64/python2.7/site-packages/gi/overrides/keysyms.pyc /usr/lib64/python2.7/site-packages/gi/overrides/__init__.pyc /usr/lib64/python2.7/site-packages/gi/_glib/__init__.pyc /usr/lib64/python2.7/site-packages/gi/_glib/option.pyc /usr/lib64/python2.7/site-packages/gi/_gobject/__init__.pyc /usr/lib64/python2.7/site-packages/gi/_gobject/constants.pyc /usr/lib64/python2.7/site-packages/gi/_gobject/propertyhelper.pyc /usr/lib64/python2.7/site-packages/gi/_gobject/signalhelper.pyc /usr/lib64/python2.7/site-packages/gi/__init__.pyc /usr/lib64/python2.7/site-packages/gi/types.pyc /usr/lib64/python2.7/site-packages/gi/module.pyc /usr/lib64/python2.7/site-packages/gi/importer.pyc /usr/lib64/python2.7/site-packages/gi/pygtkcompat.pyc Fixed for me with the attached patch that zaps py-compile (previous python.eclass ebuild used to have python_clean_py-compile_files) and uses python_optimize.
@python team, what's your opinion on this ?
py-compile is Doing It Wrong, but what else is new? Chris's patch seems reasonable.
Maybe python_clean_py-compile_files from python.eclass could be imported to python-utils-r1.eclass to prevent people from going back to stop byte compiling with random ways on every ebuild (like occurred in the past)
(In reply to comment #2) > py-compile is Doing It Wrong, but what else is new? For reference: what is py-compile doing wrong? How are python-3.3 modules supposed to be byte-compiled?
(In reply to comment #4) It is overriding the "cfile" name in py_compile.compile(file, cfile, ...). If it did not specify a value for cfile, the py_compile module should automatically put the py[co] files in the correct place. http://docs.python.org/3/library/py_compile.html
Created attachment 333538 [details, diff] py-compile automake-1.11 vs automake-1.12 This has actually been fixed in automake-1.12. See attached patch.
(In reply to comment #4) To expand on this: Up to python3.1, byte compiling a module called "dir/module.py" produces a file called "dir/module.pyc". From python3.2 forward, byte-compiling a module called "dir/module.py" should produce a file like "dir/__pycache__/module.cpython-32.pyc". The py-compile program from automake-1.11 and earlier does not account for the newer behavior.
(In reply to comment #6) > Created attachment 333538 [details, diff] [details, diff] > py-compile automake-1.11 vs automake-1.12 > > This has actually been fixed in automake-1.12. See attached patch. Considering this, I'd rather add a func to update py-compile. But not sure if the eclass is the right place to do. Maybe something like elibtoolize in autotools.eclass should do this?
Looks like it was only fixed in the very latest automake-1.12.6: http://git.savannah.gnu.org/cgit/automake.git/tree/NEWS Bugs fixed in 1.12.6: * Python-related bugs: - The default installation location for python modules has been improved for Python 3 on Debian and Ubuntu systems, changing from: ${prefix}/lib/python3/dist-packages to ${prefix}/lib/python3.x/site-packages This change should ensure modules installed using the default ${prefix} "/usr/local" are found by default by system python 3.x installations. See automake bug#10227. - Python byte-compilation supports the new layout mandated by PEP-3147, with its __pycache__ directory (automake bug#8847).
(In reply to comment #8) elibtoolize is only for patching libtool related files
This should be fixed now since ebuild doesn't force older automake versions and, then, latest one will be used (and latest one in stable is already fixed)
