Re: [Pythonmac-SIG] newbie Mac switcher trying to set up django on Intel MacBook Pro Tiger
Jack Jansen wrote: > The real problem is when I couldn't care less about package X but I'm > really interested in Y, which uses X, and then X forcing me to upgrade > it. Just to make sure I understand -- is this an example of that: I want to use wxPython (the most recent version). I expect to have to install that, but now the website tells me that I need to install the python.org python before I can use wxPython. Yes, that is annoying, but > Python is in a pretty good shape right now, with well-packaged > extension modules being compatible with a fairly wide range of Python > installations, but please let's try and keep it that way. Keep it what way? My experience and reading tells me that if I use the python.org 2.5 Universal Framework, I'll get a python that will work on OS-X 10.3.9 to 10.5.*, PPC and Intel, AND applications I build with py2app will work on those platforms, AND extensions I build with it will also work on all those platforms (with the same Python anyway). That's the state of affairs that I'm trying to keep. It appears that encouraging people to use Apple's python with OS-X 10.5 will break that state. I don't run 10.5, but from what I've seen, it's just introduced complexity and questions on this mailing list, a LOT of extra complexity for people building binaries to distribute. Jack Jansen wrote: > I think this would be a very good idea, even if only from a "political" > point of view. well, yes, the politics are relevant. > Even though I've been an open source developer since long before the > word existed I find that I'm getting sick and tired of the > reinvent-the-world attitude that is far too common in the open source > community. I really don't think this is re-invent the world. > If I am new to Python on the Mac and I've played with Apple Python a > little, but as soon as I want to install one little add-on module I have > to first replace the whole existing Python with something new (and not > directly Apple-endorsed) This was discussed a lot a while back, mostly on the context of what the common Python-on-Mac web sites should recommend to newbies. http://wiki.python.org/moin/MacPython/PythonDistributionsForMac """ Mac OS X comes with a pre-installation of Python, usually one or two years old. This can be sufficient for some needs, but the MacPython community recommends installing a newer, more capable, version. """ seems to be what was settled on then. Maybe Apple's python really is good enough to be considered the "default", but I have my doubts. Anyway, the reason to make that recommendation up front was that it's a lot less bothersome to new users to say: Want to try python? -- install this, then, when you need any extra packages, get them here. Then to get them used to using the built-in one, but when you start doing something "real", you need to go get another one. To use your example, far worse than: "as soon as I want to install one little add-on module I have to first replace the whole existing Python with something new" is "after using Apple's python for a while, and installing a bunch of extra packages into it, I now discover that it won't work for my needs, and I have to replace not only python, but all the extra packages I had already installed" Will that happen? I don't know, but I suspect it will. And frankly, once you're downloading and installing one thing, two isn't really a big deal -- unless you suffer from very limited bandwidth. OH, and it sounds like we're proposing asking new users to install a "Apple'sPythonFix" package anyway, so the ONLY difference is bandwidth, and the fact that you're not using the version from Apple -- is there really anyone that ONLY runs Apple software? > it's mightily inconvenient. Also note that the chances that the > distutils fix or the 64-bit fix are likely to affect me are exactly zero Not so. The distutils issue effects you in two ways -- 1) it's really not that rare to have to compile things -- and maybe you want to use py2app to distribute something. 2) You want binaries from someone else, and they aren't right, because they compiled them with Apple's python. Anyway, I'd love it if Apple's Python really could meet all of our needs, so go prove me wrong! Oh, and one way or another, someone should update that Wiki page for 10.5. -Chris -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception [EMAIL PROTECTED] ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Leopard easy_install chokes on appscript egg
Has, On 21 Dec, 2007, at 22:37, has wrote: Hi all, Just ran into the following problem when trying to install appscript 0.18.0 into Leopard's default Python installation via easy_install (setuptools 0.6c3): has$ /usr/bin/easy_install appscript Searching for appscript Reading http://pypi.python.org/simple/appscript/ Reading http://appscript.sourceforge.net Reading http://freespace.virgin.net/hamish.sanderson/appscript.html Best match: appscript 0.18.0 Downloading http://pypi.python.org/packages/source/a/appscript/appscript-0.18.0.tar.gz#md5 =8c013f0489349f145089c71d6d747859 Processing appscript-0.18.0.tar.gz Running appscript-0.18.0/setup.py -q bdist_egg --dist-dir /var/ folders/ p+/p+pBAQxKE-S81g-RmJ1K8U+++TI/-Tmp-/easy_install-7MwieU/ appscript-0.18.0/egg-dist-tmp-deTIQh Traceback (most recent call last): [...] -TypeError: Error when calling the metaclass bases first argument must be callable Two things: 1. Any ideas on why it's selecting the .tar.gz version rather than the .egg? (Note: the egg was built using my own Python 2.5 installation, rather than the Apple one.) That's a buglet in Python, fixed in what will be 2.5.2. Apple's python doesn't do universal binaries and setuptools doesn't know that an 'fat' egg will do on a 'ppc' or 'i386' platform. 2. I get the above traceback when easy_install tries to use the source- based appscript. This occurs with Leopard's own Python 2.5 and the Python 2.4 installation I keep around for testing purposes. Any guesses on what's going wrong? I'm not that familiar with setuptools and its error reporting leaves something to be desired, so I don't even know if the problem lies with it or appscript's setup.py script. My guess is that this a buglet in setuptools sandboxing code. Can you build an egg using Apple's python and install that (that is run 'setup.py bdist_egg' and then install that egg. Ronald smime.p7s Description: S/MIME cryptographic signature ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] newbie Mac switcher trying to set up django on Intel MacBook Pro Tiger
On 23 Dec, 2007, at 9:01, Christopher Barker wrote: Jack Jansen wrote: The real problem is when I couldn't care less about package X but I'm really interested in Y, which uses X, and then X forcing me to upgrade it. Just to make sure I understand -- is this an example of that: I want to use wxPython (the most recent version). I expect to have to install that, but now the website tells me that I need to install the python.org python before I can use wxPython. Yes, that is annoying, but That should be a documentation bug, either that or their installer sucks. Any framework build of python2.5 on OSX can use extensions build using any other framework build of python2.5. This is by design, back in the old times (OSX 10.1 and python2.3 IIRC) we had some serious problems with that (e.g. you build an extension with one build of python, use it with another build and get some very hard to understand or debug error messages). Python is in a pretty good shape right now, with well-packaged extension modules being compatible with a fairly wide range of Python installations, but please let's try and keep it that way. Keep it what way? My experience and reading tells me that if I use the python.org 2.5 Universal Framework, I'll get a python that will work on OS-X 10.3.9 to 10.5.*, PPC and Intel, AND applications I build with py2app will work on those platforms, AND extensions I build with it will also work on all those platforms (with the same Python anyway). That's the state of affairs that I'm trying to keep. It appears that encouraging people to use Apple's python with OS-X 10.5 will break that state. The right way (TM) to go forward is investigate what causes these problems and fix them, not tell people to reinstall the same version of Python they already have on their system. I don't run 10.5, but from what I've seen, it's just introduced complexity and questions on this mailing list, a LOT of extra complexity for people building binaries to distribute. I've seen two types of problems: 1) Apple's build is slightly broken in that it doesn't build universal binaries 2) If you have both Apple's build of python and the Python.org build on the system people get confused I've also found, and *fixed*, a problem in the code in distutils that determines if it is possible to universal binaries on the current platform. Jack Jansen wrote: I think this would be a very good idea, even if only from a "political" point of view. well, yes, the politics are relevant. Even though I've been an open source developer since long before the word existed I find that I'm getting sick and tired of the reinvent-the-world attitude that is far too common in the open source community. I really don't think this is re-invent the world. Why do you think it isn't? Your suggestion is just as annoying as Fink or MacPorts which insist on installing software I already have on my system. I understand the technical reasons for doing this (it makes QA a bit easier), but that doesn't make it less annoying. If I am new to Python on the Mac and I've played with Apple Python a little, but as soon as I want to install one little add-on module I have to first replace the whole existing Python with something new (and not directly Apple-endorsed) This was discussed a lot a while back, mostly on the context of what the common Python-on-Mac web sites should recommend to newbies. http://wiki.python.org/moin/MacPython/PythonDistributionsForMac """ Mac OS X comes with a pre-installation of Python, usually one or two years old. This can be sufficient for some needs, but the MacPython community recommends installing a newer, more capable, version. """ That was true on 10.3 and 10.4, but not on 10.5. The version on 10.5 is the bleeding edge of the stable branch and includes features that the Python.org tree does not (dtrace support). seems to be what was settled on then. Maybe Apple's python really is good enough to be considered the "default", but I have my doubts. Anyway, the reason to make that recommendation up front was that it's a lot less bothersome to new users to say: Want to try python? -- install this, then, when you need any extra packages, get them here. Then to get them used to using the built-in one, but when you start doing something "real", you need to go get another one. To use your example, far worse than: "as soon as I want to install one little add-on module I have to first replace the whole existing Python with something new" is "after using Apple's python for a while, and installing a bunch of extra packages into it, I now discover that it won't work for my needs, and I have to replace not only python, but all the extra packages I had already installed" Will that happen? I don't know, but I suspect it will. And frankly, once you're downloading and installing one thing, two isn't really a big deal -- u
[Pythonmac-SIG] Tk 8.5 and leopard.
I've just seen that a new version of Tk has been released, and the screenshots suggest that it will blend in much better on the mac platoform. What is going to be the best way of installing the new Tk and a version of python that can use it, without upsetting apple's python install (which I'm using with Xcode...) I hope that question makes sense... Best wishes, N ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] newbie Mac switcher trying to set up django on Intel MacBook Pro Tiger
Ronald Oussoren wrote: > > On 23 Dec, 2007, at 9:01, Christopher Barker wrote: > >> Jack Jansen wrote: >>> The real problem is when I couldn't care less about package X but I'm >>> really interested in Y, which uses X, and then X forcing me to upgrade >>> it. >> >> Just to make sure I understand -- is this an example of that: >> >> I want to use wxPython (the most recent version). I expect to have to >> install that, but now the website tells me that I need to install the >> python.org python before I can use wxPython. Yes, that is annoying, >> but > > That should be a documentation bug, either that or their installer > sucks. Yeah, I'm working on it. The current (and only, I think) issue with the installer is that it is pretty dumb about what path it chooses to install to. -- Robin Dunn Software Craftsman http://wxPython.org Java give you jitters? Relax with wxPython! ___ Pythonmac-SIG maillist - Pythonmac-SIG@python.org http://mail.python.org/mailman/listinfo/pythonmac-sig
