Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 509794 - dev-python/pypy doesn't correctly install cffi module _tkinter
Summary: dev-python/pypy doesn't correctly install cffi module _tkinter
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Development (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Python Gentoo Team
URL:
Whiteboard:
Keywords: NeedPatch
Depends on:
Blocks:
 
Reported: 2014-05-07 14:51 UTC by Ian Delaney (RETIRED)
Modified: 2014-05-09 06:14 UTC (History)
0 users

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


Attachments
executable python script (import.py,3.78 KB, text/x-python)
2014-05-07 14:51 UTC, Ian Delaney (RETIRED)
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Ian Delaney (RETIRED) gentoo-dev 2014-05-07 14:51:14 UTC
Created attachment 376546 [details]
executable python script

The downstream effect of this is that python packages that require importing of tk in the form of _tkinter are crippled because the ebuild currently fails to correctly install the module, if it does even install it.

1. PYTHON_REQ_USE cannot include tk for packages targeted to support pypy because pypy HAS NO tk IUSE flag.
2. It's apparent that not all gentoo installs have the _tkinter module. It's presence is therefore problematic / unreliable.

Initially the core of the problem could be addressed by simply adding lines at the end of the ebuild's src_install to import it along with the other explicitly listed cffi modules prior to install to the system, if not at the end of the src_compile phase.  The steps required are to 
a) ensure the _tkinter module is in fact built and
b) import it as root prior to the system install.

This clearly beckons the adding of an IUSE tk flag for the pypy ebuild.
The attached script is a cutdown of package.py found in a subfolder in the pypy source which executes the steps to import and and all cffi modules and is to be run after the actual compile or build.  Whether this is invoked via the ebuild or the importing is done, as it is currently within src_install, is a matter of style and preference.  The import.py script is open to further re-writing, mostly in the from of reducing it since it carries 'stuff' that was written for a manual install from the source. The rest of the actions in the full package.py script are not needed in gentoo, requiring the code that does the required importing to be 'lifted out'.

NB  There are only a handful of python packages that come under this category, but one is enough
Comment 1 Mike Gilbert gentoo-dev 2014-05-08 17:29:59 UTC
I don't think we should maintain a custom python script here. Just implement it in the ebuild please.

If the is something upstream will maintain, that's a different matter.
Comment 2 Ian Delaney (RETIRED) gentoo-dev 2014-05-09 00:03:11 UTC
maintain? It's lifted out from a script from the pypy source.  Does this qualify as custom?  I didn't write it, they did.  That it would need be maintained is somewhat presumptuous.  However it's merely a means to an end.  Having src_install extended is merely an alternate means.  I quite like the method at this point without being staunchly committed.
Comment 3 Mike Gilbert gentoo-dev 2014-05-09 00:51:40 UTC
(In reply to Ian Delaney from comment #2)
> maintain? It's lifted out from a script from the pypy source.

No, it is a heavily modified copy of package.py from the pypy source. Nothing was "lifted out".

> Does this qualify as custom?

Yes.

> I didn't write it, they did.  That it would need be
> maintained is somewhat presumptuous.

You hacked it up and served it up.

Who is going to keep this up to date whenever pypy upstream cuts a new release. Somebody would need to "maintain" it.

I don't see the advantage to maintaining our own script as compared to implementing the necessary code in the ebuild itself. This does not make anyone's life easier, and just adds a weird script to FILESDIR.
Comment 4 Mike Gilbert gentoo-dev 2014-05-09 01:30:15 UTC
I think a small(er) patch against package.py might be a good idea; that keeps most of the maintenance burden on upstream.
Comment 5 Ian Delaney (RETIRED) gentoo-dev 2014-05-09 04:00:29 UTC
(In reply to Mike Gilbert from comment #4)
> I think a small(er) patch against package.py might be a good idea; that
> keeps most of the maintenance burden on upstream.

actually I quite agree.

~/cvsPortage/gentoo-x86/dev-python/pylint $ pypy
Python 2.7.3 (87aa9de10f9ca71da9ab4a3d53e0ba176b67d086, May 08 2014, 11:25:46)
[PyPy 2.2.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
And now for something completely different: ``<cami> I like workin with pypy,
it's like speaking chinese''
>>>> import _tkinter
>>>> exit()

For all its hackery, it works.  Overall, both paths can work. I still like the notion of patching package.py and afaict it's historically quite a static script.  Whatever maintenance will be required is somewhere between 
0 - just a little.  It does indeed " keeps most of the maintenance burden on upstream."  But really what's so new about having to maintain patches.  It happens all the time with other packages.  This one shows all signs of being nil to low maintanance.

They could warrant separate bugs but meh.
1. The install triggers un-needed unwanted compiling of modules in the test folder.  This can be evaded by either upgrading the eclass to 
-x the test folder in the final step 
python_optimize "${ED%/}${INSDESTTREE}"
or delete / exclude the test folder being installed at all which doesn't require any edit to the eclass.
2. clone this
tk? ( >=dev-lang/tk-8.0
                dev-tcltk/blt )
from cpython
plus
! use tk && rm -r "${ED%/}${INSDESTTREE}"/lib-python/*2.7/_tkinter || die
or a whole if then statement.
Without the use of the patched package.py / import.py it beckons
plus
"${PYTHON}" -c "import syslog" || die "Failed to import syslog"
given this is done within package.py.

It appears that in cpython the modules are built if the options are set.  In pypy they're built by default but for tk which comes with an option --without-tk.  At this point I see no such options for syslog or sqlite, but they might be in there.

gettin' there
Comment 6 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2014-05-09 05:42:49 UTC
Does your fancy method work when you uninstall tk and build pypy afterwards? If it doesn't, then your arguing is pointless since you add a lot of magic and leave the automagic dep.
Comment 7 Ian Delaney (RETIRED) gentoo-dev 2014-05-09 05:44:41 UTC
(In reply to Michał Górny from comment #6)
> Does your fancy method work when you uninstall tk and build pypy afterwards?
> If it doesn't, then your arguing is pointless since you add a lot of magic
> and leave the automagic dep.

then why you don't you something about addressing the automagic dep?
That would be fancy
Comment 8 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2014-05-09 06:14:58 UTC
+  09 May 2014; Michał Górny <mgorny@gentoo.org> pypy-bin-2.2.1-r1.ebuild:
+  Add USE=tk for tkinter modules. Update the list of cffi-compiled modules. Bug
+  #509794.

+  09 May 2014; Michał Górny <mgorny@gentoo.org> pypy-2.2.1.ebuild:
+  Add USE=tk for tkinter modules. Update the list of cffi-compiled modules. Bug
+  #509794.

+  09 May 2014; Michał Górny <mgorny@gentoo.org> pypy-2.2.1.ebuild:
+  Add USE=tk for tkinter modules. Bug #509794.