[Debian-med-packaging] Bug#767145: That long-standing nasty Tcl/Tk-bug with autodocktools Re: Bitte weiterleiten (Re: [Pkg-tcltk-devel] Tcl/Tk help needed (Was: Bug#767145: autodocktools: fails to start the GUI))

[Andreas Tille]

Hi Michel,

On Wed, Feb 10, 2016 at 09:31:47AM -0800, Michel Sanner wrote:
> On 02/09/2016 11:35 PM, Andreas Tille wrote:
> >thanks for the attempt to help.  To answer your question from the other
> >mail: In Debian we need to build from source and build against the
> >current development tools - thus the usage of higher Tcl/Tk version.
> >(Just a personal remark: I think there are better GUI tools available
> >for Python than Tcl/Tk - but that's just a side note and I have not
> >investigated how much work droping Tcl/Tk might create).
> We actually stopped all TK-based developments and have started writing
> the next generation tools based on Qt. These tools will be much more user
> friendly
> up to date and efficient, but unfortunately they do not yet provide the
> level
> of functionality and stability needed to replace the existing AutoDockTools.

That's *very* good news - at least for the long term.  Very good
decision.

> >Run ADT from  /usr/lib/python2.7/dist-packages/AutoDockTools
> >Traceback (most recent call last):
> >   File "/usr/lib/python2.7/dist-packages/AutoDockTools/__init__.py", line 420, in runADT
> >     from mglutil.splashregister.splashscreen import SplashScreen
> >   File "/usr/lib/python2.7/dist-packages/mglutil/splashregister/splashscreen.py", line 7, in <module>
> >     from mglutil.util.misc import ensureFontCase
> >   File "/usr/lib/python2.7/dist-packages/mglutil/util/misc.py", line 19, in <module>
> >     import numpy.oldnumeric as Numeric
> >ImportError: No module named oldnumeric
> >hit enter to continue
> This is the very reason we gave up on trying to use system wide packages and
> bundle up a self-consistent
> Python interpreter, python packages and libraries. Some third party packages
> we have been using sometime
> require a specific version of a python package and we have no choice other
> than using this specific version.
> IHMO this is bound to happen when you integrate a large number of software
> packages and you do not have control
> over all of them.

You will find pros and cons for every strategy.  I do not see any sense
to discuss this here in private - we have several threads about this on
our mailing lists.  If only the authors of those tools would understand
that breaking the API is bad...
 
> For the new generation of our tools we already got rid of all Numeric
> references but this was not done for AutoDockTools
> which is out-of-date and not easy to maintain. However it has a large user
> base and the Tk version still is, as of today,
> the official stable version. So I will put one of my programmers on the
> project to update AutoDockTools to use numpy.
> 
> I hope this is the only instance left where we run into this kind of
> problems

Thanks a lot for your support

    Andreas.

-- 
http://fam-tille.de