[Pythonmac-SIG] Re: Which installer to use for MacPython-OSX?

[bill fancher]

On Thursday, August 22, 2002, at 01:39  PM, Jack Jansen wrote:

>
> On woensdag, augustus 21, 2002, at 11:30 , bill fancher wrote:
>>> I think Rudo meant this as a requirement for a true Mac software, not 
>>> as a description of the current state of MacPython
>>>
>>> This is a requirement from the Aqua Human Interface Guidelines (page 
>>> 246)
>>> :
>>>
>>> Always let users choose a specific folder (or the Desktop) as the 
>>> installation
>>>
>>> destination. Don't require your application to be installed in a 
>>> particular
>>>
>>> location.
>>
>> You're right about isolated applications, but we're talking about 
>> installing several applications, a framework, and various other bits. 
>> The main issue here is the framework. Frameworks are not as relocatable 
>> as applications. They generally need to live in certain "well-known" 
>> locations to work.
>
> ... but still, Rudo and Martina have a point. It would be nice if we 
> could set things up in such a way that people can install into any 
> location and have it work from there.

I wish I could install Apple's Developer Tools to a different partition.

>  Not only would it allow people to install Python in, say, Desktop Folder,
>  because they want to try it out before committing,

And I wish I could do THAT with the new Jaguar Developer Tools. Seriously,
  though, this is the KIND of thing I had in mind when I said that it might 
make sense to allow installation to "non-standard" locations. I wouldn't 
go so far as to advocate coding things specifically in the apps or 
installer scripts to support it.

>  but it would also allow you to carry a fully functional Python 
> installation with you on removable media such as a CDROM or solidstate 
> usb disk.

Ah, there's the example I was looking for.

You can (should be able to?) do that now. In sh, just do:

prefix=/Volumes/yourCD/Library/Frameworks/Python.framework/Versions/2.X
make
make frameworkinstall

Then set your PATH (if you use command-line stuff), and 
DYLD_FRAMEWORK_PATH (or DYLD_FALLBACK_FRAMEWORK_PATH). You could do that 
in a shell and launch stuff from there or make a nice ~/.MacOS/environment.
plist and double-click the apps. But see below about DYLD_FRAMEWORK_PATH.

One thing to ponder is what such an "installation" looks like. I believe 
people will be unpleasantly surprised. If we install to /tmp, e.g., we end 
up with stuff in /tmp/Applications/Python, 
tmp/Library/Frameworks/Python.framework and, maybe, /tmp/usr/local/bin.

I'd rather see an un-install package for the shoppers. That would be 
generally useful as well. And I'd let people who want to carry an 
installation around deal with their own environments. Providing some 
details on how to do that down near the bottom of "Welcome.txt" might be 
desirable.

> The DYLD_FRAMEWORK_PATH might point to a solution for this, but can we 
> exploit it? Is there a way in which we could modify the environment when 
> the user double-clicks PythonIDE so that the interpreter inside it will 
> find Python.framework? Can we set environment variables from the plist 
> file, or something similar?

AFAIK, info.plist files are only used by other apps, and the "info" in an 
info.plist is not conveyed by startup code to the app whose info.plist it 
is.

I don't think any user code gets called before libraries are loaded so 
setting DYLD_FRAMEWORK_PATH would have to be done, e.g., in some process 
that modifies the environment and then execs the REAL app. But how would 
THAT code know where to find the framework?

(You could also create or modify ~/.MacOS/environment.plist during 
installation, and have people log out/in so that it would get read. But 
that stops working if the framework is moved, and is probably rude to 
begin with. Nor does it help the person who installs to a CD and wants to 
run Python on another machine.)

The other thing to note here is that DYLD_FRAMEWORK_PATH is (at least in 
my reading of the docs) more of a special purpose tool than a variable 
intended for general use. It doesn't, e.g., get transfered with the rest 
of the environment to processes run by sudo, so Python would fail to run 
in such circumstances. From "man dyld":

"DYLD_FRAMEWORK_PATH This is a colon separated list of directories that 
contain frameworks. The dynamic linker searches these directories before 
it searches for the framework by its install name. It allows you to test 
new versions of existing frameworks."

DYLD_FRAMEWORK_PATH is also useful for things like building Python, where 
you need to use a framework that isn't yet installed in one of the "usual 
places".

DYLD_FALLBACK_FRAMEWORK_PATH would probably be better, but I'm not 
convinced solutions involving either one are a good idea.

> Alternative idea: could we pull a trick with relative paths? the 
> interpreter is built with a relative path to the framework, if we create 
> a symlink Python.framework beside the interpreter deep inside PythonIDE's 
> app bundle, would that work? The installer (probably the post-install 
> script) would have to know that the framework is installed in a place 
> where it won't be found by the normal framework search process and add 
> the symlink. BuildApplet would have to do the same.

It might work until the path to the framework changes. Worst case: the 
shopper decides Python is nice and "finishes" the installation by dragging 
apps to ~/Applications and dragging the apparently useless 
Python.framework to the trash (or any other non-standard location).

To sloganize a bit:

Tell us what works in the Welcome screen. Let us install where we like 
(like good "conservatives", we'll "take personal responsibility for our 
actions"). If you want to be REALLY nice, provide an uninstall package, so 
we can change our minds, and some tips on making things work with 
"non-standard" installation locations.

No tricks needed. Minimal labor. (We might also consider tmk's suggestion 
about an optional self-contained app.)

--
bill