On 22-jun-2006, at 19:37, Konrad Hinsen wrote: > On Jun 22, 2006, at 19:20, Ronald Oussoren wrote: > >> You can't please them all :-(. I'll add a warning to the readme >> text in the installer. You can turn this feature of during >> installation, the profile-editing step is a seperate package that >> you can disable using the 'Customize' button. This feature was >> discussed on this list > > OK, that's fine. I do occasionally read the readmes ;-)
This is the readme at the start of the installer, you'll have to at least glance at it to install Python. > >> The current installers only install a number of symlinks in /usr/ >> local/bin, the real cannonical installation location is inside the >> python framework. The reason for this is > > I noticed, and that makes sense. > >> installation of python in the default location), but more >> importantly because distutils will by default install new scripts >> into the bin directory inside the framework. This confuses the >> heck out of most users that install new python packages from >> source, even long-time Python users. By placing the framework on >> the path thing "just work". > > That is a good argument. But if you want to change $PATH > systemwide, why not put it in .MacOSX/environment.plist? That would > have an effect in all shells and also in programs like Emacs that > look for a python executable on $PATH. Moreover, it wouldn't bother > me because my .profile redefines the path completely :-) We don't put it in ~/MacOSX/environment.plist because that file sucks. There's no way to update the value of PATH, you have to provide a complete replacement. This is too bad because I'd love to update the environment for all programs. Another disadvantage of environment.plist is that not many people know about it, using it would upset even more people that the ones that don't like updates to the shell profile. > >> Now that I've defended myself it's time to move forward again ;-). >> Why do some applications require Fink python? Is that a >> convenience issue or does Fink's python do something that the >> framework install cannot do? Or to phrase it differently, what should > > It's not so much the framework build as the fact that the binary > installers have Tkinter set up for Tcl/Tk-Aqua. Fink python is set > up for Tk/X11. Tcl-Aqua still has some bugs, and apparently also > some more serious issues with multi-threading user interfaces. > > An example of a program that doesn't work with Tk-Aqua is PyMOL > (pymol.sourceforge.net). If you multi-threading user interfaces are interfaces that update the GUI from multiple threads I'm not surprised that this doesn't work with the Aqua version of Tk. The native GUI model of OSX doesn't allow this either. Tk-Aqua also has some serious L&F issues, which is very annoying because we're shipping IDLE as the standard python IDE and because IDLE uses Tk it still looks bad even after some surgery to fix all issues that I could fix (move menu's around and implement file-open- event support). According to some Tcl/Tk sites you should use some other Tcl library to get a good native L&F, but that isn't wrapped yet and I definitely won't do that. > >> change to make you drop Fink or Darwinports for python stuff? And >> I mean that *very* broadly, I'd like to make MacPython the obvious >> choice for anyone that works with python on the mac. > > That's a good plan - I'd love to get rid of Fink if I could! I use DarwinPorts to install unix/x11 tools. Having someone else hunt down patches to make stuff work on darwin is much more convenient than doing it myself. But a seperate unix installation shouldn't be necessary to use Python. Ronald _______________________________________________ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
