GNU bug report logs -
#20889
python Tkinter
Previous Next
Reported by: Federico Beffa <beffa <at> ieee.org>
Date: Wed, 24 Jun 2015 07:15:02 UTC
Severity: normal
Done: ludo <at> gnu.org (Ludovic Courtès)
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 20889 in the body.
You can then email your comments to 20889 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-guix <at> gnu.org
:
bug#20889
; Package
guix
.
(Wed, 24 Jun 2015 07:15:03 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Federico Beffa <beffa <at> ieee.org>
:
New bug report received and forwarded. Copy sent to
bug-guix <at> gnu.org
.
(Wed, 24 Jun 2015 07:15:03 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
The python package does not provide Tkinter which is part of the
Python Standard Library
https://docs.python.org/3/library/tkinter.html?highlight=tkinter#module-tkinter
Information forwarded
to
bug-guix <at> gnu.org
:
bug#20889
; Package
guix
.
(Sat, 04 Jul 2015 00:35:03 GMT)
Full text and
rfc822 format available.
Message #8 received at 20889 <at> debbugs.gnu.org (full text, mbox):
On 06/24/2015 09:14 AM, Federico Beffa wrote:
> The python package does not provide Tkinter which is part of the
> Python Standard Library
> https://docs.python.org/3/library/tkinter.html?highlight=tkinter#module-tkinter
>
I think we need to add tcl and tk to the inputs, and add the
corresponding "-I" and "-L" flags to the configure flags. The issue is
that tk depends on Python (through libx11, which depends on libxcb,
which depends on Python), so we end up with a circular dependency
leading to what I reported in
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=20967 .
I think we should:
- rename the Python package to "python-without-tkinter" or
"python-minimal" and use that as a dependency in xorg.scm;
- define a "python" package that would inherit the "minimal Python"
package and add the dependency on tcl/tk to it.
WDYT ?
Information forwarded
to
bug-guix <at> gnu.org
:
bug#20889
; Package
guix
.
(Sun, 05 Jul 2015 10:17:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 20889 <at> debbugs.gnu.org (full text, mbox):
Cyril Roelandt <tipecaml <at> gmail.com> skribis:
> On 06/24/2015 09:14 AM, Federico Beffa wrote:
>> The python package does not provide Tkinter which is part of the
>> Python Standard Library
>> https://docs.python.org/3/library/tkinter.html?highlight=tkinter#module-tkinter
>>
>
> I think we need to add tcl and tk to the inputs, and add the
> corresponding "-I" and "-L" flags to the configure flags. The issue is
> that tk depends on Python (through libx11, which depends on libxcb,
> which depends on Python), so we end up with a circular dependency
> leading to what I reported in
> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=20967 .
>
> I think we should:
> - rename the Python package to "python-without-tkinter" or
> "python-minimal" and use that as a dependency in xorg.scm;
> - define a "python" package that would inherit the "minimal Python"
> package and add the dependency on tcl/tk to it.
How frequently do Python packages rely on the availability of Tkinter?
I’m asking because it might be that we could keep the default Python
without Tk, and only use the Tk-enabled Python for the few packages that
need it, if it’s rare enough.
WDYT?
Ludo’.
Information forwarded
to
bug-guix <at> gnu.org
:
bug#20889
; Package
guix
.
(Sun, 05 Jul 2015 22:40:03 GMT)
Full text and
rfc822 format available.
Message #14 received at 20889 <at> debbugs.gnu.org (full text, mbox):
On 07/05/2015 12:16 PM, Ludovic Courtès wrote:
> I’m asking because it might be that we could keep the default Python
> without Tk, and only use the Tk-enabled Python for the few packages that
> need it, if it’s rare enough.
No, we do not want that. Users who install Python expect to be able to
import tkinter, since it is part of the standard library.
Cyril.
Information forwarded
to
bug-guix <at> gnu.org
:
bug#20889
; Package
guix
.
(Mon, 06 Jul 2015 07:28:01 GMT)
Full text and
rfc822 format available.
Message #17 received at 20889 <at> debbugs.gnu.org (full text, mbox):
On Mon, Jul 6, 2015 at 12:39 AM, Cyril Roelandt <tipecaml <at> gmail.com> wrote:
> On 07/05/2015 12:16 PM, Ludovic Courtès wrote:
>> I’m asking because it might be that we could keep the default Python
>> without Tk, and only use the Tk-enabled Python for the few packages that
>> need it, if it’s rare enough.
>
> No, we do not want that. Users who install Python expect to be able to
> import tkinter, since it is part of the standard library.
I agree with Cyril.
Information forwarded
to
bug-guix <at> gnu.org
:
bug#20889
; Package
guix
.
(Mon, 06 Jul 2015 10:22:01 GMT)
Full text and
rfc822 format available.
Message #20 received at 20889 <at> debbugs.gnu.org (full text, mbox):
Federico Beffa <beffa <at> ieee.org> skribis:
> On Mon, Jul 6, 2015 at 12:39 AM, Cyril Roelandt <tipecaml <at> gmail.com> wrote:
>> On 07/05/2015 12:16 PM, Ludovic Courtès wrote:
>>> I’m asking because it might be that we could keep the default Python
>>> without Tk, and only use the Tk-enabled Python for the few packages that
>>> need it, if it’s rare enough.
>>
>> No, we do not want that. Users who install Python expect to be able to
>> import tkinter, since it is part of the standard library.
>
> I agree with Cyril.
OK. Then we effectively need to proceed as you suggest: Build
python-minimal (which does not depend on Tk), build Tk, and then build
python.
But we should make sure that python-minimal is not retained, if
possible.
Ludo’.
Information forwarded
to
bug-guix <at> gnu.org
:
bug#20889
; Package
guix
.
(Mon, 06 Jul 2015 11:18:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 20889 <at> debbugs.gnu.org (full text, mbox):
On Mon, Jul 06, 2015 at 12:21:11PM +0200, Ludovic Courtès wrote:
> OK. Then we effectively need to proceed as you suggest: Build
> python-minimal (which does not depend on Tk), build Tk, and then build
> python.
And maybe this python-minimal could be smaller than the current python,
in the sense of "minimal"?
Andreas
Reply sent
to
ludo <at> gnu.org (Ludovic Courtès)
:
You have taken responsibility.
(Wed, 07 Oct 2015 22:21:01 GMT)
Full text and
rfc822 format available.
Notification sent
to
Federico Beffa <beffa <at> ieee.org>
:
bug acknowledged by developer.
(Wed, 07 Oct 2015 22:21:02 GMT)
Full text and
rfc822 format available.
Message #28 received at 20889-done <at> debbugs.gnu.org (full text, mbox):
ludo <at> gnu.org (Ludovic Courtès) skribis:
> OK. Then we effectively need to proceed as you suggest: Build
> python-minimal (which does not depend on Tk), build Tk, and then build
> python.
Done in commits 95288fc and afa181f.
Thanks,
Ludo’.
Information forwarded
to
bug-guix <at> gnu.org
:
bug#20889
; Package
guix
.
(Wed, 07 Oct 2015 22:21:03 GMT)
Full text and
rfc822 format available.
Message #31 received at 20889-done <at> debbugs.gnu.org (full text, mbox):
ludo <at> gnu.org (Ludovic Courtès) skribis:
> OK. Then we effectively need to proceed as you suggest: Build
> python-minimal (which does not depend on Tk), build Tk, and then build
> python.
Done in commits 95288fc and afa181f.
Thanks,
Ludo’.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Thu, 05 Nov 2015 12:24:04 GMT)
Full text and
rfc822 format available.
bug unarchived.
Request was from
Federico Beffa <beffa <at> ieee.org>
to
control <at> debbugs.gnu.org
.
(Mon, 09 Nov 2015 09:39:02 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-guix <at> gnu.org
:
bug#20889
; Package
guix
.
(Mon, 09 Nov 2015 09:43:01 GMT)
Full text and
rfc822 format available.
Message #38 received at 20889 <at> debbugs.gnu.org (full text, mbox):
If I start python3 and do:
-------------------------------------------------------
$ python3
Python 3.4.3 (default, Oct 9 2015, 22:53:58)
[GCC 4.9.3] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import tkinter
>>> root = tkinter.Tk()
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/gnu/store/y5x6c38fzrbfl80jxrgjd6py2k88x12a-python-3.4.3/lib/python3.4/tkinter/__init__.py",
line 1851, in __init__
self.tk = _tkinter.create(screenName, baseName, className,
interactive, wantobjects, useTk, sync, use)
_tkinter.TclError: Can't find a usable tk.tcl in the following directories:
/gnu/store/sd4fcdk9yzh1s0230fjx1yfwk9pl71bf-tcl-8.6.4/lib/tcl8.6/tk8.6
/gnu/store/sd4fcdk9yzh1s0230fjx1yfwk9pl71bf-tcl-8.6.4/lib/tk8.6
/gnu/store/y5x6c38fzrbfl80jxrgjd6py2k88x12a-python-3.4.3/lib/tk8.6
/gnu/store/lib/tk8.6
/gnu/store/y5x6c38fzrbfl80jxrgjd6py2k88x12a-python-3.4.3/library
This probably means that tk wasn't installed properly.
-------------------------------------------------------
Did you successfully test it?
Regards,
Fede
Information forwarded
to
bug-guix <at> gnu.org
:
bug#20889
; Package
guix
.
(Mon, 09 Nov 2015 10:38:01 GMT)
Full text and
rfc822 format available.
Message #41 received at 20889 <at> debbugs.gnu.org (full text, mbox):
with:
$TCLLIBPATH=/gnu/store/c4rpx4050d0qkccwbzggabag403b31l3-tk-8.6.4/lib python3
it works. So I guess that 'tcl' needs a search-path-specification.
Regards,
Fede
Information forwarded
to
bug-guix <at> gnu.org
:
bug#20889
; Package
guix
.
(Mon, 09 Nov 2015 11:01:02 GMT)
Full text and
rfc822 format available.
Message #44 received at 20889 <at> debbugs.gnu.org (full text, mbox):
... and the configure script for Python defines the flag
'--with-tcltk-libs'. Maybe that would help...
Regards,
Fede
Information forwarded
to
bug-guix <at> gnu.org
:
bug#20889
; Package
guix
.
(Wed, 11 Nov 2015 21:46:01 GMT)
Full text and
rfc822 format available.
Message #47 received at 20889 <at> debbugs.gnu.org (full text, mbox):
Federico Beffa <beffa <at> ieee.org> skribis:
> >>> root = tkinter.Tk()
> Traceback (most recent call last):
> File "<stdin>", line 1, in <module>
> File "/gnu/store/y5x6c38fzrbfl80jxrgjd6py2k88x12a-python-3.4.3/lib/python3.4/tkinter/__init__.py",
> line 1851, in __init__
> self.tk = _tkinter.create(screenName, baseName, className,
> interactive, wantobjects, useTk, sync, use)
> _tkinter.TclError: Can't find a usable tk.tcl in the following directories:
> /gnu/store/sd4fcdk9yzh1s0230fjx1yfwk9pl71bf-tcl-8.6.4/lib/tcl8.6/tk8.6
> /gnu/store/sd4fcdk9yzh1s0230fjx1yfwk9pl71bf-tcl-8.6.4/lib/tk8.6
> /gnu/store/y5x6c38fzrbfl80jxrgjd6py2k88x12a-python-3.4.3/lib/tk8.6
> /gnu/store/lib/tk8.6
> /gnu/store/y5x6c38fzrbfl80jxrgjd6py2k88x12a-python-3.4.3/library
This error message comes from Tcl, in file ‘auto.tcl’, procedure
‘tcl_findLibrary’.
We’d need to find where the call comes from and hard-code a search path
in there maybe?
> Did you successfully test it?
I just did “import tkinter.”
> with:
>
> $TCLLIBPATH=/gnu/store/c4rpx4050d0qkccwbzggabag403b31l3-tk-8.6.4/lib python3
>
> it works. So I guess that 'tcl' needs a search-path-specification.
Yes. That wouldn’t help for Python though, where we need to hard-code
the search path somehow.
> ... and the configure script for Python defines the flag
> '--with-tcltk-libs'. Maybe that would help...
I don’t think it would help because Python finds Tcl and Tk anyway.
Thanks,
Ludo’.
Information forwarded
to
bug-guix <at> gnu.org
:
bug#20889
; Package
guix
.
(Thu, 12 Nov 2015 13:00:06 GMT)
Full text and
rfc822 format available.
Message #50 received at 20889 <at> debbugs.gnu.org (full text, mbox):
宋文武 <iyzsong <at> openmailbox.org> skribis:
> From 6c9ea521e88d36bd1ce990a561477ec0e2950017 Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?=E5=AE=8B=E6=96=87=E6=AD=A6?= <iyzsong <at> gmail.com>
> Date: Thu, 12 Nov 2015 13:31:19 +0800
> Subject: [PATCH] tk: Hardcode path to TK_LIBRARY.
>
> Fixes <http://bugs.gnu.org/20889>.
>
> * gnu/packages/patches/tk-find-library.patch: New patch.
> * gnu-system.am (dist_patch_DATA): Add it.
> * gnu/packages/tcl.scm (tk)[source]: Add patch.
[...]
> +++ b/gnu/packages/patches/tk-find-library.patch
> @@ -0,0 +1,30 @@
> +This patch hardcode where Tk found its script library during package
^^ ^^^^
“This patch hard-codes the Tk library directory during package
initialization.”
OK with this change. Thanks for providing a quick fix! :-)
Could you commit it in a new ‘tk-update’ branch?
At the same time, I think we should move tkinter*.so to a separate
output of the Python packages; I think it’s a matter of moving the .so
to a separate output, literally. Would you like to give it a try?
Thanks!
Ludo’.
Information forwarded
to
bug-guix <at> gnu.org
:
bug#20889
; Package
guix
.
(Fri, 13 Nov 2015 11:56:02 GMT)
Full text and
rfc822 format available.
Message #53 received at 20889 <at> debbugs.gnu.org (full text, mbox):
ludo <at> gnu.org (Ludovic Courtès) writes:
> 宋文武 <iyzsong <at> openmailbox.org> skribis:
>
>> From 6c9ea521e88d36bd1ce990a561477ec0e2950017 Mon Sep 17 00:00:00 2001
>> From: =?UTF-8?q?=E5=AE=8B=E6=96=87=E6=AD=A6?= <iyzsong <at> gmail.com>
>> Date: Thu, 12 Nov 2015 13:31:19 +0800
>> Subject: [PATCH] tk: Hardcode path to TK_LIBRARY.
>>
>> Fixes <http://bugs.gnu.org/20889>.
>>
>> * gnu/packages/patches/tk-find-library.patch: New patch.
>> * gnu-system.am (dist_patch_DATA): Add it.
>> * gnu/packages/tcl.scm (tk)[source]: Add patch.
>
> [...]
>
>> +++ b/gnu/packages/patches/tk-find-library.patch
>> @@ -0,0 +1,30 @@
>> +This patch hardcode where Tk found its script library during package
> ^^ ^^^^
> “This patch hard-codes the Tk library directory during package
> initialization.”
>
> OK with this change. Thanks for providing a quick fix! :-)
>
> Could you commit it in a new ‘tk-update’ branch?
Done.
>
> At the same time, I think we should move tkinter*.so to a separate
> output of the Python packages; I think it’s a matter of moving the .so
> to a separate output, literally. Would you like to give it a try?
I don't know much about python, so I'd like to leave it for others :-)
Information forwarded
to
bug-guix <at> gnu.org
:
bug#20889
; Package
guix
.
(Mon, 16 Nov 2015 08:44:02 GMT)
Full text and
rfc822 format available.
Message #56 received at 20889 <at> debbugs.gnu.org (full text, mbox):
In ‘tk-update’ the ‘python’ packages now have a separate ‘tk’ output for
Tkinter (adding ~50 MiB to the closure of Python.) I’ve tested it along
these lines, for 2.x and 3.x:
guix environment --ad-hoc python python:tk --pure -- python
> import Tkinter
> root = Tkinter.Tk()
One thing I haven’t checked is whether some packages need to have an
additional python:tk input. Matplotlib maybe? Federico?
I plan to have Hydra build that branch once we’ve checked that.
Thanks,
Ludo’.
Information forwarded
to
bug-guix <at> gnu.org
:
bug#20889
; Package
guix
.
(Mon, 16 Nov 2015 11:46:01 GMT)
Full text and
rfc822 format available.
Message #59 received at 20889 <at> debbugs.gnu.org (full text, mbox):
On Mon, Nov 16, 2015 at 9:42 AM, Ludovic Courtès <ludo <at> gnu.org> wrote:
> In ‘tk-update’ the ‘python’ packages now have a separate ‘tk’ output for
> Tkinter (adding ~50 MiB to the closure of Python.) I’ve tested it along
> these lines, for 2.x and 3.x:
>
> guix environment --ad-hoc python python:tk --pure -- python
> > import Tkinter
> > root = Tkinter.Tk()
>
> One thing I haven’t checked is whether some packages need to have an
> additional python:tk input. Matplotlib maybe? Federico?
Yes, given that the back-end currently used by matploblib doesn't
work, I would change that by using 'Tkinter'.
Since you are at it, I would also change the default back-end by
changing 'GTK3Agg' to 'TkAgg' in the following snippet:
(lambda (port)
(format port "[rc_options]~%
backend = GTK3Agg~%")))))
I'm not convinced that having 2 versions of packages (a "normal" and a
"minimal" one) is a good idea. The reason is that you often end up
downloading both instead of just one. As one example, I just
downloaded 'vlc' and I noticed that it downloaded both 'cups' and
'cups-minimal'. Similarly, for python, anyone needing 'Tkinter' will
end up with 2 versions in the store.
Regards,
Fede
Information forwarded
to
bug-guix <at> gnu.org
:
bug#20889
; Package
guix
.
(Mon, 16 Nov 2015 12:59:01 GMT)
Full text and
rfc822 format available.
Message #62 received at 20889 <at> debbugs.gnu.org (full text, mbox):
Federico Beffa <beffa <at> ieee.org> skribis:
> On Mon, Nov 16, 2015 at 9:42 AM, Ludovic Courtès <ludo <at> gnu.org> wrote:
>> In ‘tk-update’ the ‘python’ packages now have a separate ‘tk’ output for
>> Tkinter (adding ~50 MiB to the closure of Python.) I’ve tested it along
>> these lines, for 2.x and 3.x:
>>
>> guix environment --ad-hoc python python:tk --pure -- python
>> > import Tkinter
>> > root = Tkinter.Tk()
>>
>> One thing I haven’t checked is whether some packages need to have an
>> additional python:tk input. Matplotlib maybe? Federico?
>
> Yes, given that the back-end currently used by matploblib doesn't
> work, I would change that by using 'Tkinter'.
>
> Since you are at it, I would also change the default back-end by
> changing 'GTK3Agg' to 'TkAgg' in the following snippet:
>
> (lambda (port)
> (format port "[rc_options]~%
> backend = GTK3Agg~%")))))
OTOH I see that Matploblib already depends on GTK+ 3.x and
python-pygobject, so maybe it’s best to stick to GTK+ by default?
> I'm not convinced that having 2 versions of packages (a "normal" and a
> "minimal" one) is a good idea. The reason is that you often end up
> downloading both instead of just one. As one example, I just
> downloaded 'vlc' and I noticed that it downloaded both 'cups' and
> 'cups-minimal'. Similarly, for python, anyone needing 'Tkinter' will
> end up with 2 versions in the store.
The ‘minimal’ variants are there to break cyclic dependencies most of
the time. This is the case for cups/cups-filters and Python/Tk.
At run time, cups indeed depends on cups-filters, which depends on
cups-minimal. In that case, as you say, we end up downloading those two
variants. But there’s not much of a choice, as was discussed during the
initial review:
https://lists.gnu.org/archive/html/guix-devel/2015-01/msg00057.html
Conversely, python does not depend on python-minimal. So python-minimal
is here just to break the cycle with Tk/libxcb, as noted in python.scm
and discussed in:
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=20889
As for Tkinter, it is in a separate “tk” output, which users can choose
to install or not. The “tk” output contains a single file, but it pulls
in Tcl/Tk.
I hope this clarifies things.
Thanks for your feedback,
Ludo’.
Information forwarded
to
bug-guix <at> gnu.org
:
bug#20889
; Package
guix
.
(Mon, 16 Nov 2015 13:18:01 GMT)
Full text and
rfc822 format available.
Message #65 received at 20889 <at> debbugs.gnu.org (full text, mbox):
On Mon, Nov 16, 2015 at 1:57 PM, Ludovic Courtès <ludo <at> gnu.org> wrote:
> Federico Beffa <beffa <at> ieee.org> skribis:
>> Yes, given that the back-end currently used by matploblib doesn't
>> work, I would change that by using 'Tkinter'.
>>
>> Since you are at it, I would also change the default back-end by
>> changing 'GTK3Agg' to 'TkAgg' in the following snippet:
>>
>> (lambda (port)
>> (format port "[rc_options]~%
>> backend = GTK3Agg~%")))))
>
> OTOH I see that Matploblib already depends on GTK+ 3.x and
> python-pygobject, so maybe it’s best to stick to GTK+ by default?
Unfortunately, the back-ends based on GTK+ are broken and I didn't
manage to find how to fix the problem.
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=20888
That's why I'm looking forward to get Tkinter :-)
>> I'm not convinced that having 2 versions of packages (a "normal" and a
>> "minimal" one) is a good idea. The reason is that you often end up
>> downloading both instead of just one. As one example, I just
>> downloaded 'vlc' and I noticed that it downloaded both 'cups' and
>> 'cups-minimal'. Similarly, for python, anyone needing 'Tkinter' will
>> end up with 2 versions in the store.
>
> The ‘minimal’ variants are there to break cyclic dependencies most of
> the time. This is the case for cups/cups-filters and Python/Tk.
>
> At run time, cups indeed depends on cups-filters, which depends on
> cups-minimal. In that case, as you say, we end up downloading those two
> variants. But there’s not much of a choice, as was discussed during the
> initial review:
>
> https://lists.gnu.org/archive/html/guix-devel/2015-01/msg00057.html
>
> Conversely, python does not depend on python-minimal. So python-minimal
> is here just to break the cycle with Tk/libxcb, as noted in python.scm
> and discussed in:
>
> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=20889
>
> As for Tkinter, it is in a separate “tk” output, which users can choose
> to install or not. The “tk” output contains a single file, but it pulls
> in Tcl/Tk.
OK. Thanks for the explanation!
Regards,
Fede
Information forwarded
to
bug-guix <at> gnu.org
:
bug#20889
; Package
guix
.
(Sun, 29 Nov 2015 22:10:03 GMT)
Full text and
rfc822 format available.
Message #68 received at 20889 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Federico Beffa <beffa <at> ieee.org> skribis:
> On Mon, Nov 16, 2015 at 1:57 PM, Ludovic Courtès <ludo <at> gnu.org> wrote:
>> Federico Beffa <beffa <at> ieee.org> skribis:
>>> Yes, given that the back-end currently used by matploblib doesn't
>>> work, I would change that by using 'Tkinter'.
>>>
>>> Since you are at it, I would also change the default back-end by
>>> changing 'GTK3Agg' to 'TkAgg' in the following snippet:
>>>
>>> (lambda (port)
>>> (format port "[rc_options]~%
>>> backend = GTK3Agg~%")))))
>>
>> OTOH I see that Matploblib already depends on GTK+ 3.x and
>> python-pygobject, so maybe it’s best to stick to GTK+ by default?
>
> Unfortunately, the back-ends based on GTK+ are broken and I didn't
> manage to find how to fix the problem.
> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=20888
>
> That's why I'm looking forward to get Tkinter :-)
Could you or someone else test this patch on current master?
Thanks in advance!
Ludo’.
[Message part 2 (text/x-patch, inline)]
diff --git a/gnu/packages/python.scm b/gnu/packages/python.scm
index 39d0751..76bda96 100644
--- a/gnu/packages/python.scm
+++ b/gnu/packages/python.scm
@@ -3190,6 +3190,7 @@ transcendental functions).")
`(("python-pyparsing" ,python-pyparsing)
("python-pygobject" ,python-pygobject)
("gobject-introspection" ,gobject-introspection)
+ ("python-tkinter" ,python "tk")
;; The 'gtk+' package (and 'gdk-pixbuf', 'atk' and 'pango' propagated
;; from 'gtk+') provides the required 'typelib' files used by
;; 'gobject-introspection'. The location of these files is set with the
@@ -3244,7 +3245,7 @@ transcendental functions).")
(call-with-output-file "setup.cfg"
(lambda (port)
(format port "[rc_options]~%
-backend = GTK3Agg~%")))))
+backend = TkAgg~%")))))
(alist-cons-after
'install 'install-doc
(lambda* (#:key outputs #:allow-other-keys)
Information forwarded
to
bug-guix <at> gnu.org
:
bug#20889
; Package
guix
.
(Mon, 30 Nov 2015 16:47:01 GMT)
Full text and
rfc822 format available.
Message #71 received at 20889 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Sun, Nov 29, 2015 at 11:09 PM, Ludovic Courtès <ludo <at> gnu.org> wrote:
> Federico Beffa <beffa <at> ieee.org> skribis:
>
>> On Mon, Nov 16, 2015 at 1:57 PM, Ludovic Courtès <ludo <at> gnu.org> wrote:
>>> Federico Beffa <beffa <at> ieee.org> skribis:
>>>> Yes, given that the back-end currently used by matploblib doesn't
>>>> work, I would change that by using 'Tkinter'.
>>>>
>>>> Since you are at it, I would also change the default back-end by
>>>> changing 'GTK3Agg' to 'TkAgg' in the following snippet:
>>>>
>>>> (lambda (port)
>>>> (format port "[rc_options]~%
>>>> backend = GTK3Agg~%")))))
>>>
>>> OTOH I see that Matploblib already depends on GTK+ 3.x and
>>> python-pygobject, so maybe it’s best to stick to GTK+ by default?
>>
>> Unfortunately, the back-ends based on GTK+ are broken and I didn't
>> manage to find how to fix the problem.
>> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=20888
>>
>> That's why I'm looking forward to get Tkinter :-)
>
> Could you or someone else test this patch on current master?
It does not work. It can't find the tcl/tk header files:
...
tkagg: no [The C/C++ header for Tk (tk.h) could not be
found. You may need to install the development
package.]
...
With the attached patch it does find the headers, but then it fails at
link time.
...
g++ -pthread -shared
-Wl,-rpath=/gnu/store/cxrqlhbr6xqgi08x3amd0lvl6m7sxx57-python-3.4.3/lib
build/temp.linux-x86_64-3.4/src/agg_py_transforms.o
build/temp.linux-x86_64-3.4/src/_tkagg.o
build/temp.linux-x86_64-3.4/extern/agg24/src/agg_bezier_arc.o
build/temp.linux-x86_64-3.4/extern/agg24/src/agg_curves.o
build/temp.linux-x86_64-3.4/extern/agg24/src/agg_image_filters.o
build/temp.linux-x86_64-3.4/extern/agg24/src/agg_trans_affine.o
build/temp.linux-x86_64-3.4/extern/agg24/src/agg_vcgen_contour.o
build/temp.linux-x86_64-3.4/extern/agg24/src/agg_vcgen_dash.o
build/temp.linux-x86_64-3.4/extern/agg24/src/agg_vcgen_stroke.o
build/temp.linux-x86_64-3.4/extern/agg24/src/agg_vpgen_segmentator.o
build/temp.linux-x86_64-3.4/extern/CXX/IndirectPythonInterface.o
build/temp.linux-x86_64-3.4/extern/CXX/cxxsupport.o
build/temp.linux-x86_64-3.4/extern/CXX/cxx_extensions.o
build/temp.linux-x86_64-3.4/extern/CXX/cxxextensions.o
-L/gnu/store/ipsq9hlk6k0w1qfiw0y0a03bxkp2clhl-tcl-8.6.4/lib
-L/gnu/store/my9wgryzpfvksng6k7h87xz9rphdwddw-tk-8.6.4/lib
-L/usr/local/lib -L/usr/local/lib
-L/gnu/store/cxrqlhbr6xqgi08x3amd0lvl6m7sxx57-python-3.4.3/lib -ltcl
-ltk -lstdc++ -lm -lpython3.4m -o
build/lib.linux-x86_64-3.4/matplotlib/backends/_tkagg.cpython-34m.so
ld: cannot find -ltcl
ld: cannot find -ltk
collect2: error: ld returned 1 exit status
error: command 'g++' failed with exit status 1
phase `build' failed after 94.8 seconds
...
Looking into the failed build directory, it seems that PKG_CONFIG_PATH
is set correctly. Still, it doesn't get the correct flags.
Regards,
Fede
[mpl.patch (text/x-diff, attachment)]
Information forwarded
to
bug-guix <at> gnu.org
:
bug#20889
; Package
guix
.
(Tue, 01 Dec 2015 20:20:03 GMT)
Full text and
rfc822 format available.
Message #74 received at 20889 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Federico Beffa <beffa <at> ieee.org> writes:
> On Sun, Nov 29, 2015 at 11:09 PM, Ludovic Courtès <ludo <at> gnu.org> wrote:
>> Federico Beffa <beffa <at> ieee.org> skribis:
> Looking into the failed build directory, it seems that PKG_CONFIG_PATH
> is set correctly. Still, it doesn't get the correct flags.
The attached patch fixes the problem and I can now plot with TkAgg :-)
Thanks for making Tkinter available!
Fede
[0001-gnu-python-matplotlib-Add-TkAgg-backend-and-update-t.patch (text/x-diff, attachment)]
Information forwarded
to
bug-guix <at> gnu.org
:
bug#20889
; Package
guix
.
(Tue, 01 Dec 2015 22:02:01 GMT)
Full text and
rfc822 format available.
Message #77 received at 20889 <at> debbugs.gnu.org (full text, mbox):
Federico Beffa <beffa <at> ieee.org> skribis:
> The attached patch fixes the problem and I can now plot with TkAgg :-)
>
> Thanks for making Tkinter available!
> Fede
>
> From b40cf5522bcc15166ca07dfbae50167203d29e2d Mon Sep 17 00:00:00 2001
> From: Federico Beffa <beffa <at> fbengineering.ch>
> Date: Tue, 1 Dec 2015 17:20:59 +0100
> Subject: [PATCH 1/2] gnu: python-matplotlib: Add 'TkAgg' backend and update to
> version '1.4.3'.
>
> * gnu/packages/python.scm (python-matplotlib): Do it.
> * gnu/packages/patches/matplotlib-setupext-tk.patch: New file.
Nice!
Please make sure to add the patch to gnu-system.am, but otherwise looks
great!
Thanks for fixing it!
I gather this addresses http://bugs.gnu.org/20888, right?
Ludo’.
Information forwarded
to
bug-guix <at> gnu.org
:
bug#20889
; Package
guix
.
(Wed, 02 Dec 2015 17:29:02 GMT)
Full text and
rfc822 format available.
Message #80 received at 20889 <at> debbugs.gnu.org (full text, mbox):
On Tue, Dec 1, 2015 at 11:00 PM, Ludovic Courtès <ludo <at> gnu.org> wrote:
> I gather this addresses http://bugs.gnu.org/20888, right?
Well, it partially solves it:
Now there is a working backend suitable for interactive plotting which
is enabled by default. However, the 'GTK3Agg' backend is still there
and still not working. At some point it would be nice to have it
working as well.
Regards,
Fede
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Thu, 31 Dec 2015 12:24:04 GMT)
Full text and
rfc822 format available.
This bug report was last modified 8 years and 112 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.