[Python-Dev] Miscellaneous 2.0 installation issues

[Eric S. Raymond]

Thomas Wouters <thomas@xs4all.net>:
> > 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.

IMO ssl isn't an issue because it's not documented as being in the standard
module set.  Readline is a minor issue because raw_input()'s functionality
changes somewhat if it's not linked, but I think we can live with this -- the
change isn't visible to calling programs.  

Hm.  It appears tkinter isn't documented in the standard set of modules 
either.  Interesting.  Technically this means I don't have a problem with
it not being built in by default, but I think there is a problem here...

My more general point is that right now Pyjthon has three classes of modules:

1. Documented as being in the core and built in by default.
2. Not documented as being in the core and not built in by default.
3. Documented as being in the core but not built in by default.

My more general claim is that the existence of class 3 is a problem,
because it compromises the "batteries are included" effect -- it means
Python users don't have a bright-line test for what will be present in
every Python (or at least every Python on an operating system
theoretically feature-compatible with theirs).

My struggle to get CML2 adopted brings this problem into particularly
sharp focus because the kernel group is allergic to big footprints or
having to download extension modules to do a build.  But the issue is
really broader than that.  I think we ought to be migrating stuff out
of class 3 into class 1 where possible and to class 2 only where
unavoidable.

>         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.

Yes, we need to do a lot more autodetection -- this is a large part of
my point.  I have nothing against distutils, but I don't see how it
solves this problem unless we assume that we'll always have Python
already available on any platform where we're building Python.

I'm willing to put my effort where my mouth is on this.  I have a lot
of experience with autoconf; I'm willing to write some of these nasty
config tests.

> > 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.

Is it?  That is not clear from the comment.  Perhaps this is just a 
documentation problem.  I'll look again.
 
> > 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.

As I said to Guido, I think it is exactly our job to deal with this sort
of grottiness.  One of Python's major selling points is supposed to be
cross-platform consistency of the API.  If we fail to do what you're
describing, we're failing to meet Python users' reasonable expectations
for the language.

> 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 ?

Please note that I am specifically *not* advocating making the build defaults
Linux-centric.  That's not my point at all.

> Maybe we just need a HOWTO document covering Setup ?

That would be a good idea.

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

I'm concerned that it will work the other way around, that CML2 won't happen
if the core does not reliably include these facilities.  In itself CML2 
not happening wouldn't be the end of the world of course, but I'm pushing on
this because I think the larger issue of class 3 modules is actually important
to the health of Python and needs to be attacked seriously.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

The Bible is not my book, and Christianity is not my religion.  I could never
give assent to the long, complicated statements of Christian dogma.
	-- Abraham Lincoln