[Python-Dev] Miscellaneous 2.0 installation issues

[Thomas Wouters]

On Wed, Dec 27, 2000 at 02:37:50PM -0500, Eric S. Raymond wrote:
> I have 2.0 up and running on RH7.0, compiled from sources.  In the process, 
> I discovered a couple of issues:

> 1. The curses module is commented out in the default Modules/Setup
> file.  This is not good, as it may lead careless distribution builders
> to ship Python 2.0s that will not be able to support the curses front
> end in CML2.  Supporting CML2 (and thus getting Python the "design
> win" of being involved in the Linux kernel build) was the major point
> of integrating the curses module into the Python core.  It is possible
> that one little "#" may have blown that.

Note that Tkinter is off by default too. And readline. And ssl. And the use
of shared libraries. We *can't* enable the cursesmodule by default, because
we don't know what the system's curses library is called. We'd have to
auto-detect that before we can enable it (and lots of other modules)
automatically, and that's a lot of work. I personally favour autoconf for
the job, but since amk is already busy on using distutils, I'm not going to
work on that.

> 2.The default Modules/Setup file assumes that various Tkinter-related libraries
> are in /usr/local.  But /usr would be a more appropriate choice under most
> circumstances.  Most Linux users now install their Tcl/Tk stuff from RPMs
> or .deb packages that place the binaries and libraries under /usr.  Under
> most other Unixes (e.g. Solaris) they were there to begin with.

This is nonsense. The line above it specifically states 'edit to reflect
where your Tcl/Tk headers are'. And besides from the issue whether they are
usually found in /usr (I don't believe so, not even on Solaris, but 'my'
Solaris box doesn't even have tcl/tk,) /usr/local is a perfectly sane
choice, since /usr is already included in the include-path, but /usr/local
usually is not.

> 3. The configure machinery could be made to deduce more about the contents
> of Modules/Setup than it does now.  In particular, it's silly that the person
> building Python has to fill in the locations of X librasries when 
> configure is in principle perfectly capable of finding them.

In principle, I agree. It's a lot of work, though. For instance, Debian
stores the Tcl/Tk headers in /usr/include/tcl<version>, which means you can
compile for more than one tcl version, by just changing your include path
and the library you link with. And there are undoubtedly several other
variants out there.

Should we really make the Setup file default to Linux, and leave other
operating systems in the dark about what it might be on their system ? I
think people with Linux and without clue are the least likely people to
compile their own Python, since Linux distributions already come with a
decent enough Python. And, please, lets assume the people assembling those
know how to read ?

Maybe we just need a HOWTO document covering Setup ?

(Besides, won't this all be fixed when CML2 comes with a distribution, Eric ?
They'll *have* to have working curses/tkinter then :-)

-- 
Thomas Wouters <thomas@xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!