[Pythonmac-SIG] sys.path for MacPython 2.3 - next set of questions

[Paul Berkowitz]

May I make a request as a new Python scripter? I'm probably coming from a
very different place than almost everyone here who has been pioneering
Python on the Mac since early days. It's natural that you are at ease with
multiple Python installations and always wanting the capability of using the
latest and best alpha, beta and release versions of Python.

What _I_ want is a default Python installation in the next and subsequent OS
versions (OS 10.3, 10.4, etc) that is optimized as far as possible. I
_never_, _ever_ will ask my users to install other builds of Python. They
will not do it. I want the OS-installed version of Python to be the best and
latest release version at the time of OS release.

For that to happen, you have to make the directory locations the ones that
_Apple_ wants. Surely picking locations analogous to what they do with their
mainstream programs like Perl is going to achieve that end. At the very
least make them local-, not user-based. Just give yourselves an opportunity
to install local-based installations for your beta and advanced work. But
please make the standard installation one that can be picked up by Apple
immediately after a new Python release without any fuss or bother.

The only way Python will receive the widespread adoption it deserves is if
good, recent versions become part of the standard OS install.

If this is all beside the point, I apologize. I'm too new to Python to have
any understanding of the specifics here, but am dimly aware that it may
affect the OS adoption issue. Just ignore this if it's irrelevant.

-- 
Paul Berkowitz



> From: Jack Jansen <Jack.Jansen@cwi.nl>
> Date: Mon, 14 Apr 2003 16:31:01 +0200
> To: Jack Jansen <Jack.Jansen@cwi.nl>
> Cc: pythonmac-sig@python.org
> Subject: Re: [Pythonmac-SIG] sys.path for MacPython 2.3 - next set of
> questions
> 
> 
> On Monday, Apr 14, 2003, at 11:54 Europe/Amsterdam, Jack Jansen wrote:
> 
>> I think I'm going to go for ~/Library/Python/2.3/site-packages, i.e.
>> scream loudly
>> if you *really* don't agree.
> 
> I just thought of a problem with the whole per-user scheme:
> distributions that install more than just modules. As an example,
> Numeric installs C header files too. This can't work (at least, not
> easily) for things installed per-user.
> 
> I first thought that duplicating the whole Python structure (so there
> would be a ~/Library/Python/lib/python2.3/site-packages, but also a
> ~/Library/Python/include/python2.3 where Numeric can dump its include
> files, etc) would do the trick but it doesn't: distutils can't live
> with two Python "installations" so packages dependent on Numeric won't
> find the new include files.
> 
> I'm not sure about a solution: maybe just forget about it, and let the
> Package Manager Manager (alias "the scapegoat") handle it, via a new
> warning mechanism in package descriptions ("This package needs to be
> installed system-wide preferably, installing it for the current user
> only results in reduced functionality").
> --
> Jack Jansen, <Jack.Jansen@cwi.nl>, http://www.cwi.nl/~jack
> If I can't dance I don't want to be part of your revolution -- Emma
> Goldman
> 
> 
> _______________________________________________
> Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
> http://mail.python.org/mailman/listinfo/pythonmac-sig
>