Re: [Pythonmac-SIG] newbie Mac switcher trying to set up django on Intel MacBook Pro Tiger

2007-12-21 Thread Jack Jansen

On 20 dec 2007, at 12:35, Ronald Oussoren wrote:

>
> That's easily fixable. I'm thinking about reviving Jack's MacPython
> addons idea: a small .mpkg that will install IDLE.app, a 64-bit
> command-line interpreter and some small fixes (such as the distutiles
> one).  That should make Leopard's builtin python a lot more useable
> without requireing people to basicly install the same version of
> python that is already on their system.


I think this would be a very good idea, even if only from a  
"political" point of view.
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.

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) I might just drop out. And at the  
very least 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 (the "newcomer me" from this paragraph, not the "flesh  
and blood Jack" me:-).
--
Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma  
Goldman


___
Pythonmac-SIG maillist  -  [email protected]
http://mail.python.org/mailman/listinfo/pythonmac-sig


Re: [Pythonmac-SIG] newbie Mac switcher trying to set up django on Intel MacBook Pro Tiger

2007-12-21 Thread Daniel Lord

On Dec 21, 2007, at 12:48 AM, Jack Jansen wrote:
> I think this would be a very good idea, even if only from a
> "political" point of view.
> 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.
> 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) I might just drop out. And at the
> very least 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 (the "newcomer me" from this paragraph, not the "flesh
> and blood Jack" me:-).

There are many who can wax more eloquently than I, maybe even  
Stallman- or Raymond-esqe about cathedrals and bazaars, on the  
material differences in the drivers behind and goals of commercial and  
open source software projects, but Jack's points about the  
isolationist tendencies and the need for "native" Python support are  
well-stated and his suggestion should be given serious consideration.  
While this community has done very well with only tacit Apple support  
(though embedding PyObjC is a bit more than tacit), we would likely  
find more support by Apple if we expand our offering to cater to the  
left half and tail of the Python adoption normal distribution. This  
would have the effect of raising Apple's awareness of the importance  
of Python on the platform. For example: I should not have to tinker  
with path settings, or worse install another a complete other Python,   
to use Python in a scriptable high-end 3D graphics modeler and  
renderer where a perfectly good one is already installed. Better  
OpenOffice Python integration and native Appscript and Python OSA  
support are others. But this means providing a reasonably rich set of  
tools that is fully accessible from the stock Python installation for  
the neophytes and apprentices as much as journeymen. I am with you Jack.

Daniel Lord

___
Pythonmac-SIG maillist  -  [email protected]
http://mail.python.org/mailman/listinfo/pythonmac-sig


Re: [Pythonmac-SIG] newbie Mac switcher trying to set up django on Intel MacBook Pro Tiger

2007-12-21 Thread Ronald Oussoren
 
On Friday, December 21, 2007, at 09:48AM, "Jack Jansen" <[EMAIL PROTECTED]> 
wrote:
>
>On 20 dec 2007, at 12:35, Ronald Oussoren wrote:
>
>>
>> That's easily fixable. I'm thinking about reviving Jack's MacPython
>> addons idea: a small .mpkg that will install IDLE.app, a 64-bit
>> command-line interpreter and some small fixes (such as the distutiles
>> one).  That should make Leopard's builtin python a lot more useable
>> without requireing people to basicly install the same version of
>> python that is already on their system.
>
>
>I think this would be a very good idea, even if only from a  
>"political" point of view.
>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.
>
>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) I might just drop out. And at the  
>very least 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 (the "newcomer me" from this paragraph, not the "flesh  
>and blood Jack" me:-).

Hear, hear...  It's not the replacing of python per-se that annoys me, it is
replacing it by *exactly the same version* that is annoying.

Contrary to what some people seem to think Apple does learn and is trying
to make Python as good as possible. They make mistakes, but hey they are
humans. 

A small package that fixes some small annoyances would make everyones 
lives easier.  It would also result in a system python that is arguably better
than the standard python.org tree: 64-bit support and dtrace support built-in.

Neither are currently available in the python.org tree, even when you built from
source. 

Ronald

>--
>Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack
>If I can't dance I don't want to be part of your revolution -- Emma  
>Goldman
>
>
>
>
___
Pythonmac-SIG maillist  -  [email protected]
http://mail.python.org/mailman/listinfo/pythonmac-sig


[Pythonmac-SIG] Leopard easy_install chokes on appscript egg

2007-12-21 Thread has
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):
   File "/usr/bin/easy_install", line 8, in 
 load_entry_point('setuptools==0.6c7', 'console_scripts',  
'easy_install')()
   File "/System/Library/Frameworks/Python.framework/Versions/2.5/ 
Extras/lib/python/setuptools/command/easy_install.py", line 1670, in  
main
 with_ei_usage(lambda:
   File "/System/Library/Frameworks/Python.framework/Versions/2.5/ 
Extras/lib/python/setuptools/command/easy_install.py", line 1659, in  
with_ei_usage
 return f()
   File "/System/Library/Frameworks/Python.framework/Versions/2.5/ 
Extras/lib/python/setuptools/command/easy_install.py", line 1674, in  

 distclass=DistributionWithoutHelpCommands, **kw
   File "/System/Library/Frameworks/Python.framework/Versions/2.5/lib/ 
python2.5/distutils/core.py", line 151, in setup
 dist.run_commands()
   File "/System/Library/Frameworks/Python.framework/Versions/2.5/lib/ 
python2.5/distutils/dist.py", line 974, in run_commands
 self.run_command(cmd)
   File "/System/Library/Frameworks/Python.framework/Versions/2.5/lib/ 
python2.5/distutils/dist.py", line 994, in run_command
 cmd_obj.run()
   File "/System/Library/Frameworks/Python.framework/Versions/2.5/ 
Extras/lib/python/setuptools/command/easy_install.py", line 211, in run
 self.easy_install(spec, not self.no_deps)
   File "/System/Library/Frameworks/Python.framework/Versions/2.5/ 
Extras/lib/python/setuptools/command/easy_install.py", line 446, in  
easy_install
 return self.install_item(spec, dist.location, tmpdir, deps)
   File "/System/Library/Frameworks/Python.framework/Versions/2.5/ 
Extras/lib/python/setuptools/command/easy_install.py", line 471, in  
install_item
 dists = self.install_eggs(spec, download, tmpdir)
   File "/System/Library/Frameworks/Python.framework/Versions/2.5/ 
Extras/lib/python/setuptools/command/easy_install.py", line 655, in  
install_eggs
 return self.build_and_install(setup_script, setup_base)
   File "/System/Library/Frameworks/Python.framework/Versions/2.5/ 
Extras/lib/python/setuptools/command/easy_install.py", line 930, in  
build_and_install
 self.run_setup(setup_script, setup_base, args)
   File "/System/Library/Frameworks/Python.framework/Versions/2.5/ 
Extras/lib/python/setuptools/command/easy_install.py", line 919, in  
run_setup
 run_setup(setup_script, args)
   File "/System/Library/Frameworks/Python.framework/Versions/2.5/ 
Extras/lib/python/setuptools/sandbox.py", line 27, in run_setup
 lambda: execfile(
   File "/System/Library/Frameworks/Python.framework/Versions/2.5/ 
Extras/lib/python/setuptools/sandbox.py", line 63, in run
 return func()
   File "/System/Library/Frameworks/Python.framework/Versions/2.5/ 
Extras/lib/python/setuptools/sandbox.py", line 29, in 
 {'__file__':setup_script, '__name__':'__main__'}
   File "setup.py", line 10, in 
   File "/System/Library/Frameworks/Python.framework/Versions/2.5/ 
Extras/lib/python/py2app/util.py", line 9, in 
 import macholib.util
   File "/System/Library/Frameworks/Python.framework/Versions/2.5/ 
Extras/lib/python/macholib/util.py", line 56, in 
 class writablefile(file):
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.)

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.



Thanks,

has
-- 
http://appscript.sourceforge.net
http://rb-appscript.rubyforge.org

___
Pythonmac-SIG maillist  -  [email protected]
http://mail.python.org/mailman/listinfo/pythonmac-sig


Re: [Pythonmac-SIG] newbie Mac switcher trying to set up django on Intel MacBook Pro Tiger

2007-12-21 Thread Jack Jansen
I've been thinking a bit more about being forced to upgrade package X  
when I'm not interested, and I realised that the times it really  
bothers me are even one more step removed: if I was interested in  
package X and the website/whatever told me "don't use the current  
version of X, use the newer one" I can probably live with that.

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.

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.
--
Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack
If I can't dance I don't want to be part of your revolution -- Emma  
Goldman


___
Pythonmac-SIG maillist  -  [email protected]
http://mail.python.org/mailman/listinfo/pythonmac-sig