At 10:41 AM 9/15/2005 -0500, Ian Bicking wrote:

One issue that has come up for me is the way setuptools currently generates scripts causes problems for me. For instance, if I do tag_svn_revision, then the version of my package can change in place (whenever I do setup.py egg_info). The script has a version hardcoded in it, and so it fails.

Run "develop" instead of "egg_info", and your active scripts will be upgraded. (The "develop" command also runs "egg_info" as a subcommand.)

Also, if we support multiple versions of packages, each with a script tied to that version, then there needs to be an easier way to control the script names, e.g., --script-suffix=0.4 or something.

That would indeed be handy.

The other issue is which Python version is used to load the script; it's not uncommon to want to switch versions. It would be nice if there was something -- an option, perhaps, or an environmental variable -- which could override the Python version. E.g. script --python-version=python2.4, or PYTHON_VERSION=python2.4 script (I don't think the later isn't reasonable to do in Windows, though)

I don't think this can be made to work in any meaningful fashion, since eggs are specific to a particular Python version (because of bytecode format differences), and may contain different modules or entry points or dependencies for different Python versions. For example, if somebody packages a new module for use with older Pythons, users of that package will likely have their setup() include a dependency for the separately-packaged module if running on the older Python. Another example: setuptools doesn't publish an entry point for the 'build_py' command when running on Python 2.4, but it does on 2.3 because the 2.3 build_py command doesn't support installing package data.

...

* Should launchers hardcode their sys.path? This would prevent breakage caused by installing new and incompatible versions of their dependencies, but require an explicit upgrade action to update them, and make the installation process more complex.

I'm wary of hardcoding paths. I don't think we should completely embrace encapsulation -- it might be better for long-term stability (maybe), but it makes it harder to fix a system that is broken (even when "brkoen" just means one missing requirement).

Well, with a sufficiently complex launcher, you could have it try to fix the problem (e.g. by running EasyInstall to find the missing bits). But I guess we can just evolve that way over time. :)

[Thomas Heller wrote]

...

There is a bug in the current cmd.exe (or maybe it is only up to Win2k? can't remember) where shell redirection doesn't work if your script is launched indirectly via a .bat of .cmd file. As well, Ctrl+C signal handling for kill a script is quite annoying if launched via a .bat file: you get a secondary question from the shell

Terminate batch file (Y/N)?

or something like that. A .exe launcher/stub is definitely preferred.

Isn't the shell redirection problem also present if the .py script is run via the shell association?

Oh shoot, I think I was wrong and you are right: the shell redirection problem is for the case of using the PATHEXT stuff. I.e. I think shell redirection works fine with a .bat or .cmd stub. Sorry about causing confusion.

The Ctrl+C behaviour annoys me also because I usually run my scripts via batch files (py23.bat, py24.bat, py_d.bat and so on). Maybe this problem can be avoided by copying the python.exe's somewhere to my path, with names p23.exe, p24.exe and so on. They only contain a pointer to the actual PythonXY.dll name, afaik. So I don't have to update p24.exe when I install 2.4.2 over my 2.4.1.

I tend to copy python.exe to pythonXY.exe (as appropriate) after I install a new Python. I'm considering doing this by default in the ActivePython installers I make. (Similar to the pythonX.Y executable copies that get made on Linux/Un*x.) What do you think?

Somewhat similar to the exemaker approach, but using the name of the exe to specify the Python version instead of a '-i ...' command line option, or the #! line in the script.

Agreed.

The only missing piece so far, for me at least, is that it's not possible to use dotted module names with the -m option:

p24 -m ctypes.wrap.h2xml windows.h

That's too bad. I didn't know "-m" didn't support that... but then I haven't really used it that much yet. Trent -- Trent Mick TrentM@ActiveState.com

At 10:00 PM 9/16/2005 +0100, Paul Moore wrote:

On 9/16/05, Trent Mick wrote:

...

...

The only missing piece so far, for me at least, is that it's not possible to use dotted module names with the -m option:

p24 -m ctypes.wrap.h2xml windows.h

That's too bad. I didn't know "-m" didn't support that... but then I haven't really used it that much yet.

There's a patch on SF to implement that (1043356 ) and a corresponding PEP (338), but I don't know what's required to get it added.

Another annoyance with -m is that it doesn't support modules in zipfiles (e.g., zipped eggs).

Really, the only reasonable way to solve both problems is something like 'python -m run foo.bar ....'. That is, have a bootstrap module to do the rest. (Or alternately, have -m fallback to using the bootstrap module if it's unsuccessful.) However, after reflection, I think now that -m probably only really makes sense for stdlib modules, since projects using setuptools can now get all the benefits of -m without any of the drawbacks, without even writing any __name__=='__main__' code. For example defining an entry point thus: [console_scripts] h2xml = ctypes.wrap.h2xml:main automatically creates 'h2xml.exe' on Windows and a #!-prefixed 'h2xml' script on any other platform. (Using the current CVS version of setuptools, that is.)

Paul Moore writes:

On 9/17/05, Phillip J. Eby wrote:

...

However, after reflection, I think now that -m probably only really makes sense for stdlib modules, since projects using setuptools can now get all the benefits of -m without any of the drawbacks, without even writing any __name__=='__main__' code.

One thing you get with -m is that the module doesn't have to be on PATH. Where does setuptools install its wrapper executables? (The usual \Python24\Scripts directory isn't added to PATH by the installer).

I know, I'm nitpicking. Sorry :-)

No, you're not. IMO. setuptools installs them in PythonXY\Scripts. BTW: Shouldn't 'setup.py develop --uninstall' remove them again? It doesn't. And yet another question: How should my setup-script start? Is this the correct way: """ from ez_setup import use_setuptools use_setuptools() from distutils.core import setup """ I'm considering to finally use setuptools in the comtypes setup script. Thomas

...

...

Where does setuptools install its wrapper executables? (The usual \Python24\Scripts directory isn't added to PATH by the installer).

setuptools installs them in PythonXY\Scripts.

Unless you set --install-scripts somewhere else, which you can do in a configuration file. To the greatest extent possible, I'm trying to have setuptools minimize surprises with respect to installation locations, by conforming to the active distutils configuration.

Does anybody else think that installing to PythonXY\Scripts (instead of to PythonXY) is broken? With Perl and Ruby, for example, scripts from a 3rd party package will be installed next to the main interpreter binary (i.e. on the PATH) on all platforms. Would having setuptools (and changing distutils) to install scripts next to python.exe wreak unwarranted havoc? Cheers, Trent -- Trent Mick TrentM@ActiveState.com

[Phillip J. Eby wrote]

...

With Perl and Ruby, for example, scripts from a 3rd party package will be installed next to the main interpreter binary (i.e. on the PATH) on all platforms. Would having setuptools (and changing distutils) to install scripts next to python.exe wreak unwarranted havoc?

Sadly, yes. First of all, python.exe isn't *on* the PATH on Windows unless you put it there yourself.

It gets on the PATH with ActivePython <wink>. I'd recommend that the python.org Python installer do the same, but I seem to remember MvL (and others?) stating their preference not to do so (don't recall why). In any case, I'd say it is extremely *common* for Windows users to put the Python install dir on their PATH -- just as it is common for Windows Perl and Ruby users to put the interpreter dir on their PATH. I'd then say that the obvious place to put user scripts installed via distutils is that same directory.

Second, the python.exe directory is on sys.path, so it would turn your scripts into modules, conflicting with any same-named modules.

That never occured to me that that could be a problem. I have a few scripts that I've been distributing for a while and haven't had a particular issue... because I tend to write so that my scripts are (somewhat) useful as modules as well. But you are right, some people could get surprised by this. Hrm. Either (1) this behaviour (Python putting the interpreter dir on sys.path) is just broken or (2) it was an intentional design and script-writers should be expected to ensure their scripts either work reasonably or at least don't cause damage when imported. Since the directory with the interpreter is NOT on sys.path on other platforms (Linux, Un*x) then I'd say this is just broken behaviour. Anyone know, off hand, *why* the Python interpreter dir is on sys.path on Windows? Trent -- Trent Mick TrentM@ActiveState.com

[Trent]

...

In any case, I'd say it is extremely *common* for Windows users to put the Python install dir on their PATH -- just as it is common for Windows Perl and Ruby users to put the interpreter dir on their PATH. I'd then say that the obvious place to put user scripts installed via distutils is that same directory.

[Thomas Heller wrote]

Well, I don't think so. It *may* be common for windows users who use the command line ;-), but I would guess that's a minority anyway.

A minority of Windows users of Python use the command line? Really? Anyone coming from Unix will immediately go there. Last I remember "Learning Python" and the Python tutorial and other intro texts encourage the user to open the interactive shell at the command line to play around. You may be right, though. Even if it is "a minority" I suspect that is still a big number. Even for that set of Windows users that *do* use the command line, having Python get on their PATH automatically just makes sense: It allows other systems that depend on Python to be able to just work after an installation. For example, the Mozilla build system on Windows requires an installation of Perl. The build instructions can just say "install ActivePerl" (which puts Perl on the user's PATH) and thereafter the build system can easily find the Perl is needs. I bet that systems out there requiring Python have more difficulty. It allows tutorials/introductory-texts to have a lowest common denominator that just works for newbies on all platforms: 1. install Python 2. type "python script.py" Then they can get on to all the subtle platform-specific bells and whistles, viz:

Even though I *use* the command line, I've never put python.exe on my PATH. It's easier to type 'myscript' or 'myscript.py' than 'python myscript.py' anyway.

That is presuming that the Windows installer set up a .py file association and put .py;.pyc;... in the PATHEXT env. var. Does putting an installed Python on the PATH cause damage in any way?

Then, I have multiple versions installed on my machine, and to select between 2.3.5, 2.4.1, and the CVS version I can always use 'py23 myscript.py', 'py24 myscript.py', 'py myscript.py' and 'py_d myscript.py' - the latter to run it with the debug compiled CVS version. I had created batchfiles py23.bat and so on which specify the directory of the python.exe or python_d.exe files.

A week or so ago I asked you what you thought of the idea of having the Windows build (and installers) have a "pythonXY.exe" or "pythonX.Y.exe" along with the usual "python.exe". This would match what is done on other platforms to allow multiple versions on Python on the PATH and still be able pick a specific one. (I'm not sure if you replied.) I do something similar to your "py23", "py24", ... thing. A common mechanism for this would be nice.

And this also explains why I'm still waiting for the extented version of the '-m' command line option and did not bother to put the PythonXY\Scripts directory on the PATH - I would loose the ability to easily switch versions.

And gain a subtle python-specific way to launch a script. I realize I am ranting above, but I just think it is crazy to have the situation these days where, for example, I download and install pychecker and then try to run it: C:\trentm\tmp>pychecker 'pychecker' is not recognized as an internal or external command, operable program or batch file. I understand your wanting a mechanism to easily be able to run any Python scripts/modules you have with any Python installation/build you have, but the common user case is just: (1) I have my latest Python installation, (2) I want to run something installed with "python setup.py install" Trent -- Trent Mick TrentM@ActiveState.com

Kevin Dangoor wrote:

On 9/15/05, Phillip J. Eby wrote:

...

As for Mac OS, I have almost no experience with it, so I'm not sure what GUI applications there need. Does everything need py2app? If you have a wx-based app, would you just make a #! script? Bob Ippolito previously mentioned that you don't "install" applications there, that people just drag applications wherever they want them rather than using shortcuts, so at least that part isn't a problem. :)

GUI apps on the Mac need py2app.

It depends. wx-based programs don't have a technical need to be in a .app bundle. They will run fine from the command line. Now, the *user* might want it packaged in a .app bundle, and we as developers might need to respond to that desire. I think that PyObjC apps might actually need to be in a .app bundle to work reliably, though. I have a feeling that there isn't a pressing need to be able to install .app bundles from easy_install. If the package maintainer is going to go to the trouble of writing a setup.py that can be used with py2app, he'll almost certainly actually build the .app binary and distribute it. Since they're standalone, they don't really interact with the other installed packages. -- Robert Kern rkern@ucsd.edu "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter

Phillip J. Eby wrote:

At 11:10 AM 9/15/2005 -0700, Robert Kern wrote:

...

I have a feeling that there isn't a pressing need to be able to install .app bundles from easy_install. If the package maintainer is going to go to the trouble of writing a setup.py that can be used with py2app, he'll almost certainly actually build the .app binary and distribute it. Since they're standalone, they don't really interact with the other installed packages.

If you can run a wx or tkinter (or other cross-platform GUI) app on Mac OS without needing anything special, but users would prefer to have the .app, it would probably be a good idea to have it, even if the original developer hasn't targeted that platform specifically. For example, packages like idle or the pydoc tkinter GUI would seem to merit something like this.

Oh, certainly it would be nice. But AFAICT, you really do have to write a setup.py specifically for py2app. The information you need isn't something you can simply divine from a generic setup.py . -- Robert Kern rkern@ucsd.edu "In the fields of hell where the grass grows high Are the graves of dreams allowed to die." -- Richard Harter