[Python-Dev] Miscellaneous 2.0 installation issues

[Eric S. Raymond]

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

I understand.  We can't, for example, guarantee to duplicate the Windows-
specific stuff in the Unix port (nor would we want to in most cases :-)).
However, I think "we build in curses/Tkinter everywhere the corresponding
libraries exist" is a guarantee we can and should make.  Similarly for
other modules presently in class 3.
 
> 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).

Yes.  We have three categories here:

1. People who use python for applications (what I've been calling users)
2. People who configure Python binary packages for distribution (what
   you call a "compiler/assembler" and I think of as a "builder").
3. People who hack Python itself.

Problem is that "developer" is very ambiguous in this context...

>           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'd like to see both things happen (HOWTO and autoconfing) and am willing to
work on both.

> I apologize for the tone of my previous post, and the above snippet.

No offense taken at all, I assure you.

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

I admit I'm not very clear on the scope of what distutils is supposed to
handle, and how.  Perhaps amk can enlighten us?

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

You've got a deal.  I'll start looking at the autoconf code.  I've already
got a fair idea how to do this.
-- 
		<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>

No one who's seen it in action can say the phrase "government help" without
either laughing or crying.