[Guido writes]

Modifyable data needs to go in a per-user directory, even on Windows, outside the Python tree.

This seems to be the value of key "AppData" stored under in HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Filders Right? Thomas

On 26 May 2000, Gordon McMillan said:

Yeah. I tend to install stuff outside the sys.prefix tree and then use .pth files. I realize I'm, um, unique in this regard but I lost everything in some upgrade gone bad. (When a Windows de- install goes wrong, your only option is to do some manual directory and registry pruning.)

I think that's appropriate for Python "applications" -- in fact, now that Distutils can install scripts and miscellaneous data, about the only thing needed to properly support "applications" is an easy way for developers to say, "Please give me my own directory and create a .pth file". (Actually, the .pth file should only be one way to install an application: you might not want your app's Python library to muck up everybody else's Python path. An idea AMK and I cooked up yesterday would be an addition to the Distutils "build_scripts" command: along with frobbing the #! line to point to the right Python interpreter, add a second line: import sys ; sys.append(path-to-this-app's-python-lib) Or maybe "sys.insert(0, ...)". Anyways, that's neither here nor there. Except that applications that get their own directory should be free to put their (static) data files wherever they please, rather than having to put them in the app's Python library. I'm more concerned with the what the Distutils works best with now, though: module distributions. I think you guys have convinced me; static data should normally sit with the code. I think I'll make that the default (instead of prefix + "share"), but give developers a way to override it. So eg.: data_files = ["this.dat", "that.cfg"] will put the files in the same place as the code (which could be a bit tricky to figure out, what with the vagaries of package-ization and "extra" install dirs); data_files = [("share", ["this.dat"]), ("etc", ["that.cfg"])] would put the data file in (eg.) /usr/local/share and the config file in /usr/local/etc. This obviously makes the module writer's job harder: he has to grovel from sys.prefix looking for the files that he expects to have been installed with his modules. But if someone really wants to do this, they should be allowed to. Finally, you could also put absolute directories in 'data_files', although this would not be recommended.

(Hmm, I guess it is if you use rpms.)

All the smart Unix installers (RPM, Debian, FreeBSD, ...?) I know of have some sort of dependency mechanism, which works to varying degrees of "work". I'm only familar with RPM, and my usual response to a dependency warning is "dammit, I know what I'm doing", and then I rerun "rpm --nodeps" to ignore the dependency checking. (This usually arises because I build my own Perl and Python, and don't use Red Hat's -- I just make /usr/bin/{perl,python} symlinks to /usr/local/bin, which RPM tends to whine about.) But it's nice to know that someone is watching. ;-) Greg -- Greg Ward - software developer gward@mems-exchange.org MEMS Exchange / CNRI voice: +1-703-262-5376 Reston, Virginia, USA fax: +1-703-262-5367

On 26 May 2000, Gordon McMillan said:

Hmm. I see an application as a module distribution that happens to have a script. (Or maybe I see a module distribution as a scriptless app ;-)).

But end-users who just want to run a Python application see it as an application; the fact that it's (largely) written in Python and includes a Python library of its own is immaterial. However, all files from that application should most likely be installed in the same place -- /usr/local/myapp or "C:\Program Files\MyApp", pick your poison. And the module developer should have the option of just dumping his stuff in /usr/local/lib/python1.x/site-packages and /usr/local/bin, or C:\Python, or whatever is the locally appropriate place to dump Python modules. Currently, of course, that's the *only* option that the Distutils easily supports. (Although I suspect that with the current code, one could craft a setup.cfg that forces the "install" command to put files wherever you damn well please. That's icky, though -- it won't deal with setting the right sys.path for your application.) [me]

An idea AMK and I cooked up yesterday would be an addition to the Distutils "build_scripts" command: along with frobbing the #! line to point to the right Python interpreter, add a second line: import sys ; sys.append(path-to-this-app's-python-lib)

Or maybe "sys.insert(0, ...)".

Oops, meant "sys.path..." there of course. [Gordon]

$PYTHONSTARTUP ??

The idea is to set sys.path for *just this application* rather than for all Python code installed on the system. This is kind of important if you have an application that defines a module "DateTime" and another, independent module called "DateTime". /usr/local/myapp/lib/python should come first in sys.path when you run myapp, and it should never be seen when you run anything else. The possibilities are: * create shell script wrappers for every Python script: eg. script1 might be PYTHONPATH=/usr/local/myapp/lib/python \ exec /usr/local/bin/python1.6 /usr/local/myapp/_script1.py * adjust the scripts at build time so set the right sys.path Nasty as it is, I incline towards the latter: if nothing else, it's more portable! But this is all speculative. The immediate aim of the Distutils is *not* full-blown Python applications, but I am starting to see how we could support such applications. A little idle speculation never hurt anyone.

That's an artifact of your code ;-). If you figured it out once, you stand at least a 50% chance of getting the same answer a second time <.5 wink>.

What!?! Are you accusing me of writing complex code? Well... ok... maybe a little bit... but only in install.py, really... the rest of it's quite straightforward! Greg -- Greg Ward - nerd gward@python.net http://starship.python.net/~gward/ I have many CHARTS and DIAGRAMS..

On 26 May 2000, Fred L. Drake said:

It's useful to remember that $PYTHONSTARTUP only affects interactive interpreters, not scripts/applications. Using this for anything related to the installed base is pretty bogus. It would also be unreliable since users won't cooperate. ;)

Thanks for the reminder. The latter also applies to PYTHONPATH: if you expect an environment variable to be set, you had bloody well better supply a shell script that sets it appropriately. (And forget about portability to Mac OS or Windows -- or at least, forget about being used on Windows by anybody except Unix refugees.) I have yet to hear howls of my revulsion at my loopy idea of sticking this: import sys; sys.path.insert(0, application-python-path) into scripts that are installed as part of a "Python application" (ie. a module distribution whose main interface is a script or scripts, and that gets its own directory rather than dangling off Python's library directory). Could it be that people actually think this is a *good* idea? ;-) Greg -- Greg Ward - maladjusted nerd gward@python.net http://starship.python.net/~gward/ Hold the MAYO & pass the COSMIC AWARENESS ...