[Python-Dev] Miscellaneous 2.0 installation issues

[Thomas Wouters]

On Thu, Dec 28, 2000 at 12:20:48PM -0500, Eric S. Raymond wrote:

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

It depends on your definition of 'being in the core'. Some of the things
that are 'in the core' are simply not possible on all platforms. So if you
want really portable code, you don't want to use them. Other features are
available on all systems that matter [to you], so you don't really care
about it, just use them, and at best document that they need feature X.

There is also the subtle difference between a Python user and a Python
compiler/assembler (excuse my overloading of the terms, but you know what I
mean). People who choose to compile their own Python should realize that
they might disable or misconfigure some parts of it. I personally trust most
people that assemble OS distributions to compile a proper Python binary +
modules, but I think a HOWTO isn't a bad idea -- unless we autoconf
everything.

> I think we ought to be migrating stuff out
> of class 3 into class 1 where possible and to class 2 only where
> unavoidable.

[ and ]

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

[ and ]

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

[ and ]

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

I apologize for the tone of my previous post, and the above snippet. I'm not
trying to block progress here ;) I'm actually all for autodetecting as much
as possible, and more than willing to put effort into it as well (as long as
it's deemed useful, and isn't supplanted by a distutils variant weeks
later.) And I personally have my doubts about the distutils variant, too,
but that's partly because I have little experience with distutils. If we can
work out a deal where both autoconf and distutils are an option, I'm happy
to write a few, if not all, autoconf tests for the currently disabled
modules.

So, Eric, let's split the work. I'll do Tkinter if you do curses. :)

However, I'm also keeping those oddball platforms that just don't support
some features in mind. If you want truly portable code, you have to work at
it. I think it's perfectly okay to say "your Python needs to have the curses
module or the tkinter module compiled in -- contact your administrator if it
has neither". There will still be platforms that don't have curses, or
syslog, or crypt(), though hopefully none of them will be Linux.

Oh, and I also apologize for possibly duplicating what has already been said
by others. I haven't seen anything but this post (which was CC'd to me
directly) since I posted my reply to Eric, due to the ululating bouts of
delay on mail.python.org. Maybe DC should hire some *real* sysadmins,
instead of those silly programmer-kniggits ? >:->

-- 
Thomas Wouters <thomas@xs4all.net>

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