[Pythonmac-SIG] Popen2

[François Granger]

I am trying to use popen2.popen3 and I am stuck.

I tested the command line I am building and it works ok. This may be due to
my lack of knowledge of the command line functionnalities... But this script
either hang or raise an error.

This is the bare bone script directly copied from the sample:

#!/usr/bin/env python
# -*- coding: utf-8 -*-

"""r, w, e = popen2.popen3('python slave.py')
e.readlines()
r.readlines()
r.close()
e.close()
w.close()"""

import popen2

theString = file('testfiles/notes.htm').read()
source = 'macintosh'
target = 'UTF-8'
r, w, e = popen2.popen3('iconv -f ' + source.upper() + ' -t ' +
target.upper() + '//TRANSLIT')
w.write(theString)
e.readlines()
result = r.readlines()
r.close()
e.close()
w.close()
print result
pass

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] Popen2

[Bob Ippolito]

On Dec 29, 2004, at 3:12 AM, François Granger wrote:
I am trying to use popen2.popen3 and I am stuck.
Don't!  Use subprocess instead.  Read this thread  
 for the last discussion on this topic (that I  
recall, anyway).

-bob
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] py2applet question

[Ronald Oussoren]

On 28-dec-04, at 22:32, Bob Ippolito wrote:
On Dec 28, 2004, at 4:14 PM, Kevin Walzer wrote:
Kevin-Walzers-Computer:~/Desktop/eric-3.5.1/eric kevin$ py2applet 
eric3.py
from: can't read /var/mail/py2app.scripts.script_py2applet
/usr/local/bin/py2applet: line 3: syntax error: unexpected end of file
Sounds like the hash-bang is missing from /usr/local/bin/py2applet.  
I'm not sure why that is, I haven't been able to reproduce with svn 
trunk.
That's because you fixed it several weeks ago :-)
Ronald
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] How badly is _locale broken?

[Ronald Oussoren]

On 28-dec-04, at 23:11, Brett C. wrote:
I am planning to attempt to fix the _locale module (which 'locale' 
itself imports and uses) for OS X.  As of this exact moment I am 
planning just fixing localeconv (thanks to CFNumberFormatter and 
setlocale still at least storing the supposed locale, even if it does 
ignore it), but I realized other stuff might be broken.

Since I never personally use the module, does anyone know the extent 
of the breakage?  Obviously I would rather just have to fix localeconv 
and keep my life simple, but if it is more extensive I can see what I 
can do.
Not linking with the CoreServices and Foundation frameworks would do 
the trick. That might cause problems elsewhere though :-(.

Ronald
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

[Pythonmac-SIG] Popen2

[Francois Granger]

I am trying to use popen2.popen3 and I am stuck.

I tested the command line I am building and it works ok. This may be due to
my lack of knowledge of the command line functionnalities... But this script
either hang or raise an error.

This is the bare bone script directly copied from the sample:

#!/usr/bin/env python
# -*- coding: utf-8 -*-

"""r, w, e = popen2.popen3('python slave.py')
e.readlines()
r.readlines()
r.close()
e.close()
w.close()"""

import popen2

theString = file('testfiles/notes.htm').read()
source = 'macintosh'
target = 'UTF-8'
r, w, e = popen2.popen3('iconv -f ' + source.upper() + ' -t ' +
target.upper() + '//TRANSLIT')
w.write(theString)
e.readlines()
result = r.readlines()
r.close()
e.close()
w.close()
print result
pass

___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

[Pythonmac-SIG] dyld trying to link against wrong version of Python

[Kersey Black]

Hi all,
I first confess to being a newbie, but that will probably be obvious.
I am trying to set up my powerbook for python work.  It has 10.3.7,  
current dev xcode tools, etc.

I want Numeric, numarrray, and scipy modules.
I thought I would upgrade to python 2.4, and tried to do so with a  
framework install.  I ran into problems (getting waste to link in the  
compile), and realized, that having never used a mac for development (I  
do have unix experience) I would be better sticking to the core system  
already provided, Python 2.3.

I then tried to use the package manager in MacPython-2.3 to install  
Numeric and numarray (from different sites). Numeric worked, numarray  
did not and was very out of date.  So, i tried to compile the new  
version(1.1.1).  I had some trouble with getting it to install, and  
while struggling with that I realized i better get rid of all traces of  
the aborted install of Python-2.4 framework.

I removed"
/Library/Frameworks/Python.framework  [the default installation site  
for 2.4 build]
/Library/Python
/Applications/MacPython-2.4
~/.idlerc
/System/Library/Frameworks/Python.framwork/Versions/2.3/Headers/numarray
and any preference files I could find related to python.

over a couple of more times through this, I also
removed and reinstalled /Applications/MacPython-2.3 (twice)
I have removed other modules (Numeric, PIL. OpenGL), because I am not  
sure if there are conflicts.

Here is the problem:
I build and install numarray-1.1.1 into the /Library/Python directory
I start Python-2.3 and ask for it to import numarray
here is what I get:
Traceback (most recent call last):
  File "", line 1, in ?
  File  
"/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ 
python2.3/site-packages/numarray/__init__.py", line 42, in ?
from numarrayall import *
  File  
"/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ 
python2.3/site-packages/numarray/numarrayall.py", line 1, in ?
from numerictypes import *
  File  
"/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ 
python2.3/site-packages/numarray/numerictypes.py", line 35, in ?
import numinclude
  File  
"/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ 
python2.3/site-packages/numarray/numinclude.py", line 4, in ?
import _ndarray
ImportError: Failure linking new module:  
/Library/Frameworks/Python.framework/Versions/2.4/Python: dyld: python  
can't open library:  
/Library/Frameworks/Python.framework/Versions/2.4/Python  (No such file  
or directory, errno = 2)

It is still trying to link against a Python-2.4, even though I think I  
have removed all traces.
Why is it trying to find the long since removed Python-2.4??

Further,
if I import sys, and then import numarray, the import error is the same.
BUT, if I import sys, try to import numarray which generates the same  
error above, then type sys.path, and then import numarray, the error  
goes away, but the import seems to have failed none the less.

>>> sys.path
['',  
'/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ 
python23.zip',  
'/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ 
python2.3',  
'/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ 
python2.3/plat-darwin',  
'/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ 
python2.3/plat-mac',  
'/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ 
python2.3/plat-mac/lib-scriptpackages',  
'/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ 
python2.3/lib-tk',  
'/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ 
python2.3/lib-dynload',  
'/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ 
python2.3/site-packages']
>>> import numarray
>>> numarray.__version__
Traceback (most recent call last):
  File "", line 1, in ?
AttributeError: 'module' object has no attribute '__version__'

Any help would be greatly appreciated.  Again, why is numarray thinking  
there is a 2.4 version.  In other environments I would just reinstall  
Python-2.3 from the ground up, but working from the Apple CDs I do not  
see how to do that.  If anyone knows how to do that, it could also be a  
solution, or not.

Cheers,
Kersey
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] How badly is _locale broken?

[Bob Ippolito]

On Dec 29, 2004, at 4:50 AM, Ronald Oussoren wrote:
On 28-dec-04, at 23:11, Brett C. wrote:
I am planning to attempt to fix the _locale module (which 'locale' 
itself imports and uses) for OS X.  As of this exact moment I am 
planning just fixing localeconv (thanks to CFNumberFormatter and 
setlocale still at least storing the supposed locale, even if it does 
ignore it), but I realized other stuff might be broken.

Since I never personally use the module, does anyone know the extent 
of the breakage?  Obviously I would rather just have to fix 
localeconv and keep my life simple, but if it is more extensive I can 
see what I can do.
Not linking with the CoreServices and Foundation frameworks would do 
the trick. That might cause problems elsewhere though :-(.
I think someone said this is fixed on 10.4, so you can just wait a 
while and it'll probably fix itself using the generic unix code.

Yes, not linking to CoreFoundation will cause problems, because 
*something* will inevitably link to CF.  For example, the py2app 
bootstrap will link to CF.  A bunch of the extension modules in 
MacPython also independently link to CF-using frameworks.

-bob
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

[Pythonmac-SIG] Re: [Python-Dev] Re: [Python-checkins] python/dist/src/Mac/OSX fixapplepython23.py, 1.1, 1.2

[Jack Jansen]

On 29-dec-04, at 4:35, Bob Ippolito wrote:
This is the wrong fix.  Distutils is dumber than you think.  This 
patch just breaks C++ compilation in a different way.  The correct 
solution is a patch to distutils of some kind.

from distutils/unixccompiler.py:174
if target_lang == "c++" and self.compiler_cxx:
linker[0] = self.compiler_cxx[0]
self.spawn(linker + ld_args)
"linker" is the variable expanded LDSHARED (or whatever comes out of 
sysconfig.customize_compiler).
Bah!
Any suggestions as to what to do to get c++ compilation fixed?
Also, could you point me to a readily available extension package that 
uses c++?
--
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  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] dyld trying to link against wrong version of Python

[Bob Ippolito]

On Dec 28, 2004, at 1:51 PM, Kersey Black wrote:
I first confess to being a newbie, but that will probably be obvious.
I am trying to set up my powerbook for python work.  It has 10.3.7,  
current dev xcode tools, etc.

I want Numeric, numarrray, and scipy modules.
I thought I would upgrade to python 2.4, and tried to do so with a  
framework install.  I ran into problems (getting waste to link in the  
compile), and realized, that having never used a mac for development  
(I do have unix experience) I would be better sticking to the core  
system already provided, Python 2.3.

I then tried to use the package manager in MacPython-2.3 to install  
Numeric and numarray (from different sites). Numeric worked, numarray  
did not and was very out of date.  So, i tried to compile the new  
version(1.1.1).  I had some trouble with getting it to install, and  
while struggling with that I realized i better get rid of all traces  
of the aborted install of Python-2.4 framework.
I would recommend not using anything from the undefined.org repository.  
 I do not actively maintain it, so everything is out of date.  I have  
no plans to update it until the infrastructure behind the package  
management crap changes, because what we have now is nasty and I just  
don't have time for it.

I removed"
/Library/Frameworks/Python.framework  [the default installation site  
for 2.4 build]
/Library/Python
/Applications/MacPython-2.4
~/.idlerc
/System/Library/Frameworks/Python.framwork/Versions/2.3/Headers/ 
numarray
and any preference files I could find related to python.
You forgot to remove your build directories.. see below.
over a couple of more times through this, I also
removed and reinstalled /Applications/MacPython-2.3 (twice)
I have removed other modules (Numeric, PIL. OpenGL), because I am not  
sure if there are conflicts.

Here is the problem:
I build and install numarray-1.1.1 into the /Library/Python directory
I start Python-2.3 and ask for it to import numarray
here is what I get:
Traceback (most recent call last):
  File "", line 1, in ?
  File  
"/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ 
python2.3/site-packages/numarray/__init__.py", line 42, in ?
from numarrayall import *
  File  
"/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ 
python2.3/site-packages/numarray/numarrayall.py", line 1, in ?
from numerictypes import *
  File  
"/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ 
python2.3/site-packages/numarray/numerictypes.py", line 35, in ?
import numinclude
  File  
"/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ 
python2.3/site-packages/numarray/numinclude.py", line 4, in ?
import _ndarray
ImportError: Failure linking new module:  
/Library/Frameworks/Python.framework/Versions/2.4/Python: dyld: python  
can't open library:  
/Library/Frameworks/Python.framework/Versions/2.4/Python  (No such  
file or directory, errno = 2)

It is still trying to link against a Python-2.4, even though I think I  
have removed all traces.
Why is it trying to find the long since removed Python-2.4??
Because it was linked when the Python 2.4 framework existed.
Further,
if I import sys, and then import numarray, the import error is the  
same.
BUT, if I import sys, try to import numarray which generates the same  
error above, then type sys.path, and then import numarray, the error  
goes away, but the import seems to have failed none the less.
Python imports will fail once, and then leave a broken module in  
sys.modules, so a second import will erroneously succeed.  It's dumb,  
but that's how Python works.

>>> sys.path
['',  
'/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ 
python23.zip',  
'/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ 
python2.3',  
'/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ 
python2.3/plat-darwin',  
'/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ 
python2.3/plat-mac',  
'/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ 
python2.3/plat-mac/lib-scriptpackages',  
'/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ 
python2.3/lib-tk',  
'/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ 
python2.3/lib-dynload',  
'/System/Library/Frameworks/Python.framework/Versions/2.3/lib/ 
python2.3/site-packages']
>>> import numarray
>>> numarray.__version__
Traceback (most recent call last):
  File "", line 1, in ?
AttributeError: 'module' object has no attribute '__version__'

Any help would be greatly appreciated.  Again, why is numarray  
thinking there is a 2.4 version.  In other environments I would just  
reinstall Python-2.3 from the ground up, but working from the Apple  
CDs I do not see how to do that.  If anyone knows how to do that, it  
could also be a solution, or not.
This is a bug in Python 2.3.0 that has been discussed A LOT on this  
list, most recently  

Re: [Pythonmac-SIG] How badly is _locale broken?

[Ronald Oussoren]

On 29-dec-04, at 11:23, Bob Ippolito wrote:
On Dec 29, 2004, at 4:50 AM, Ronald Oussoren wrote:
On 28-dec-04, at 23:11, Brett C. wrote:
I am planning to attempt to fix the _locale module (which 'locale' 
itself imports and uses) for OS X.  As of this exact moment I am 
planning just fixing localeconv (thanks to CFNumberFormatter and 
setlocale still at least storing the supposed locale, even if it 
does ignore it), but I realized other stuff might be broken.

Since I never personally use the module, does anyone know the extent 
of the breakage?  Obviously I would rather just have to fix 
localeconv and keep my life simple, but if it is more extensive I 
can see what I can do.
Not linking with the CoreServices and Foundation frameworks would do 
the trick. That might cause problems elsewhere though :-(.
I think someone said this is fixed on 10.4, so you can just wait a 
while and it'll probably fix itself using the generic unix code.

Yes, not linking to CoreFoundation will cause problems, because 
*something* will inevitably link to CF.  For example, the py2app 
bootstrap will link to CF.  A bunch of the extension modules in 
MacPython also independently link to CF-using frameworks.
I know that. But not linking with CoreServices should fix _locale for 
python scripts that don't use mac-specific features.

The correct fix would probably use CFLocale to implement the _locale 
module on OSX.

Ronald
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] Re: [Python-Dev] Re: [Python-checkins] python/dist/src/Mac/OSX fixapplepython23.py, 1.1, 1.2

[Bob Ippolito]

On Dec 29, 2004, at 5:23 AM, Jack Jansen wrote:
On 29-dec-04, at 4:35, Bob Ippolito wrote:
This is the wrong fix.  Distutils is dumber than you think.  This 
patch just breaks C++ compilation in a different way.  The correct 
solution is a patch to distutils of some kind.

from distutils/unixccompiler.py:174
if target_lang == "c++" and self.compiler_cxx:
linker[0] = self.compiler_cxx[0]
self.spawn(linker + ld_args)
"linker" is the variable expanded LDSHARED (or whatever comes out of 
sysconfig.customize_compiler).
Bah!
Any suggestions as to what to do to get c++ compilation fixed?
I can think of two ways:
1. Patch distutils to actually do 
os.environ['MACOSX_DEPLOYMENT_TARGET'] = '10.3' because CCompiler.spawn 
doesn't take an environment dict.
2. Patch distutils to skip over environment variables (basically change 
that "0" into something smarter).   This is probably less desirable 
because who knows where this happens, and who knows what third party 
compiler subclasses used this original stupid code as a template.

In either case, setting the environment variable should only be done if 
it's not already set, and it should raise if is set to anything lower 
than 10.3.  For example, an existing MACOSX_DEPLOYMENT_TARGET variable 
of 10.4 should be allowed.  Values smaller than 10.3 should not be 
allowed because they are incompatible with the linker feature we're 
trying to enable.

Also, could you point me to a readily available extension package that 
uses c++?
I have no idea, but I remember this issue was brought up at some point 
during one of the many discussions of this issue.  I think it was also 
mentioned that SciPy's distutils extensions (or is it a fork?) does 
something similarly stupid when frobbing in a Fortran compiler.

-bob
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] How badly is _locale broken?

[Bob Ippolito]

On Dec 29, 2004, at 5:32 AM, Ronald Oussoren wrote:
On 29-dec-04, at 11:23, Bob Ippolito wrote:
On Dec 29, 2004, at 4:50 AM, Ronald Oussoren wrote:
On 28-dec-04, at 23:11, Brett C. wrote:
I am planning to attempt to fix the _locale module (which 'locale' 
itself imports and uses) for OS X.  As of this exact moment I am 
planning just fixing localeconv (thanks to CFNumberFormatter and 
setlocale still at least storing the supposed locale, even if it 
does ignore it), but I realized other stuff might be broken.

Since I never personally use the module, does anyone know the 
extent of the breakage?  Obviously I would rather just have to fix 
localeconv and keep my life simple, but if it is more extensive I 
can see what I can do.
Not linking with the CoreServices and Foundation frameworks would do 
the trick. That might cause problems elsewhere though :-(.
I think someone said this is fixed on 10.4, so you can just wait a 
while and it'll probably fix itself using the generic unix code.

Yes, not linking to CoreFoundation will cause problems, because 
*something* will inevitably link to CF.  For example, the py2app 
bootstrap will link to CF.  A bunch of the extension modules in 
MacPython also independently link to CF-using frameworks.
I know that. But not linking with CoreServices should fix _locale for 
python scripts that don't use mac-specific features.
Well, my patch to remove all non-libSystem dependencies from the Python 
core was accepted for Python 2.4, so we are already at this point.  
However, the mac toolbox functions can lazily import CF-using modules.  
I think the core probably uses some of these functions.  Last I 
remember, the locale module itself linked to CF (directly or 
indirectly) so it could guess what the current locale should be :)

The correct fix would probably use CFLocale to implement the _locale 
module on OSX.
Yes, that would be a good fix.
Alternatively, we could just punt on the issue and say "you need to use 
10.X in order to have a working locale module", where 10.X is the 
version that Apple fixes CF.  X is obviously greater than 3, but I 
don't think it will be much greater.  It's been broken for this long, 
and Brett C. said he doesn't use the locale module, so it may be too 
much effort for too little reward.

-bob
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] How badly is _locale broken?

[Michael Hudson]

Bob Ippolito <[EMAIL PROTECTED]> writes:

> Alternatively, we could just punt on the issue and say "you need to
> use 10.X in order to have a working locale module", where 10.X is the
> version that Apple fixes CF.  X is obviously greater than 3, but I
> don't think it will be much greater.  It's been broken for this long,
> and Brett C. said he doesn't use the locale module, so it may be too
> much effort for too little reward.

It would be nice if the unit tests stop failing, though.

Cheers,
mwh

-- 
  Screaming 14-year-old boys attempting to prove to each other that
  they are more 3133t than j00.
 -- Reason #8 for quitting slashdot today, from
http://www.cs.washington.edu/homes/klee/misc/slashdot.html
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] How badly is _locale broken?

[Bob Ippolito]

On Dec 29, 2004, at 6:06 AM, Michael Hudson wrote:
Bob Ippolito <[EMAIL PROTECTED]> writes:
Alternatively, we could just punt on the issue and say "you need to
use 10.X in order to have a working locale module", where 10.X is the
version that Apple fixes CF.  X is obviously greater than 3, but I
don't think it will be much greater.  It's been broken for this long,
and Brett C. said he doesn't use the locale module, so it may be too
much effort for too little reward.
It would be nice if the unit tests stop failing, though.
So skip them and disable (or at least throw up a warning that says 
those locale functions don't actually work) the module if not using 
10.X or later.

-bob
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

[Pythonmac-SIG] Kodos

[Kevin Walzer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I have a working app bundle of Kodos put together...I haven't released
it because I wasn't sure anyone would be interested in it, but it works
fine with my PyQt-Mac distribution. Let me know if you'd like me to post
it for download.
- --
Cheers,
Kevin Walzer, PhD
WordTech Software--Open Source Applications and Packages for OS X
http://www.wordtech-software.com
http://www.smallbizmac.com
http://www.kevin-walzer.com
mailto:[EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (Darwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFB0s3hJmdQs+6YVcoRAvIuAJ4+4G31sPmDM0Z/ufrul0u3w1Lc3wCghgt8
3mlrb6FLlqehCL73pQh4FGQ=
=LlBW
-END PGP SIGNATURE-
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

[Pythonmac-SIG] BuildApplet in next distro of MacPython?

[Kevin Walzer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I'm curious about whether BuildApplet and PythonIDE will be included in
the next iteration of MacPython, or whether these will be replaced by
py2app and PyOxide. Although I know these are old technologies,
especially BuildApplet, I'd like to request that they be retained, even
if they're not updated or enhanced.
The reason I'm asking is that I make extensive use of BuildApplet in the
packages I maintain. I've had inconsistent luck with BundleBuilder,
py2app, and py2applet--mostly bad luck.
The nice thing about BuildApplet that it is, in fact, very simple, even
dumb, in creating applications: it saves the script in question, that's
it. It then becomes a simple matter to add the additional scripts that
come with an application to the app bundle in the appropriate directory,
to edit the info.plist file, to change the icon, etc.
In short, I have control over almost the entire process of packaging.
And I've documented this process pretty thoroughly at my website.
I realize there are tradeoffs with this approach. Apps I bundle with
BuildApplet don't have their external dependencies included (wxPython,
PyQt, whatever). But if those external dependencies are installed on the
~ user machine, then the BuildApplet process works flawlessly.
py2app is a lot more elegant and smarter in what it does in terms of
packaging, but it's also more complex. That is, if there's an error,
it's very hard--at least for me--to debug. The build process dies. I
tested this yesterday with both py2app and py2applet with Eric3, an
application I have successfully with BuildApplet. With both py2app and
py2applet, something didn't get included, even though Bob has now added
PyQt support to py2app. Neither he nor I could figure out what the
problem was. The result was that the bundle created with py2app crashed,
while py2applet just died during the build process.
This isn't a complaint about py2app: I've tested it with simpler
applications and it works beautifully. By all means, it should be the
featured method for packaging apps in MacPython. But if BuildApplet and
PythonIDE can be retained, even if it's deprecated, that would be
enormously helpful to me.
A workable alternative would be if Glenn Andreas continued to include
support for BuildApplet in PyOxide. Glenn, is this possible?
Cheers,
Kevin Walzer, PhD
WordTech Software--Open Source Applications and Packages for OS X
http://www.wordtech-software.com
http://www.smallbizmac.com
http://www.kevin-walzer.com
mailto:[EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (Darwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFB0uIaJmdQs+6YVcoRAuqLAJ9s5DDormJMRtyH/Lp1KccYCF/cLgCeMfKO
WWWCmzfcOh5KCQXq/0nZTjY=
=vwbz
-END PGP SIGNATURE-
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] BuildApplet in next distro of MacPython?

[Bob Ippolito]

On Dec 29, 2004, at 11:58 AM, Kevin Walzer wrote:
I'm curious about whether BuildApplet and PythonIDE will be included in
the next iteration of MacPython, or whether these will be replaced by
py2app and PyOxide. Although I know these are old technologies,
especially BuildApplet, I'd like to request that they be retained, even
if they're not updated or enhanced.
Nothing is going away anytime soon.  I'm sure your concerns will be 
addressed by the time this is even an issue, assuming that you are 
willing to request features and report bugs to py2app.

The reason I'm asking is that I make extensive use of BuildApplet in 
the
packages I maintain. I've had inconsistent luck with BundleBuilder,
py2app, and py2applet--mostly bad luck.
If you give up on reporting issues and whatnot with py2app it's not 
ever going to suit your needs.

py2app's alias build mode (-A) is equivalent to what BuildApplet does 
*except* the output isn't *ever* portable to other machines because it 
keeps references not copies to the scripts and data files.  It works 
perfectly fine for "from IDE" use.

The nice thing about BuildApplet that it is, in fact, very simple, even
dumb, in creating applications: it saves the script in question, that's
it. It then becomes a simple matter to add the additional scripts that
come with an application to the app bundle in the appropriate 
directory,
to edit the info.plist file, to change the icon, etc.

In short, I have control over almost the entire process of packaging.
And I've documented this process pretty thoroughly at my website.
Adding dependencies by hand is really sketchy.  In order to do it 
right, it basically has to be all or nothing (until py2app has an 
interactive mode anyway).  Right now py2app's "nothing" option is not 
portable to other machines.  However since py2app alias bundles are so 
quick to create and the output is so small you can just make one at the 
destination machine.  Which of course, already has "everything", 
including py2app.

It is not even possible to correctly include the following, very 
common, kinds of dependencies after-the-fact:
1. Are compiled with an unpatched Python or
2. Are compiled in a 10.2 compatible way
3. Depend on third party dylibs

By "not even possible" I mean that you won't do it correctly unless you 
REALLY know what you are doing with install_name_tool, etc.  If you 
did, you would probably rather had py2app do it for you anyway, because 
I guarantee it's not any fun.

I realize there are tradeoffs with this approach. Apps I bundle with
BuildApplet don't have their external dependencies included (wxPython,
PyQt, whatever). But if those external dependencies are installed on 
the
~ user machine, then the BuildApplet process works flawlessly.
That's an extremely big if and is only really relevant if you're 
distributing software to other Python developers or inside of a 
controlled organization.

py2app's alias mode works a lot like that, except it's not portable to 
other machines because aliases and symlinks are used internally.  
However, in both scenarios where BuildApplet's output is useful, this 
is actually reasonable.  Python developers can type "python setup.py 
py2app -A" themselves.  In a controlled organization, this could be 
done as part of the installation process for your application, since 
py2app and everything else will already be installed by other means.

py2app is a lot more elegant and smarter in what it does in terms of
packaging, but it's also more complex. That is, if there's an error,
it's very hard--at least for me--to debug. The build process dies. I
tested this yesterday with both py2app and py2applet with Eric3, an
application I have successfully with BuildApplet. With both py2app and
py2applet, something didn't get included, even though Bob has now added
PyQt support to py2app. Neither he nor I could figure out what the
problem was. The result was that the bundle created with py2app 
crashed,
while py2applet just died during the build process.
If you want "stupid" output from py2app, pass --site-packages.  This 
means your applications will work locally, since the missing modules 
will be searched for in the normal manner, but your application now has 
a high probability of not working on another machine.  Hopefully it's 
obvious why this is not the default.

Since you were unwilling to even post the results of my suggestion 
yesterday, implicating me in "neither he nor I could figure out..." is 
a bad way to put it.  Basically, you haven't yet done anything beyond 
your initial message to help me figure it out, and are throwing your 
hands up because I didn't immediately know what kind of craziness is 
involved in Eric3 and how that affects py2app off the top of my head.

That said, the way to solve this problem is to create a setup.py and 
tweak the includes option until the application has everything it 
needs.  Write down which modules you had to add, and then figure out 
why the heck they were missing.  I

Re: [Pythonmac-SIG] BuildApplet in next distro of MacPython?

[Kevin Walzer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Bob Ippolito wrote:
|
|
| If you give up on reporting issues and whatnot with py2app it's not ever
| going to suit your needs.
I won't stop reporting bugs. Frankly, part of the issue is that I don't
have time to learn py2app deeply. At some point in the near future, I'm
going to drill more deeply into it.
|
|
| Adding dependencies by hand is really sketchy.  In order to do it right,
| it basically has to be all or nothing (until py2app has an interactive
| mode anyway).  Right now py2app's "nothing" option is not portable to
| other machines.  However since py2app alias bundles are so quick to
| create and the output is so small you can just make one at the
| destination machine.  Which of course, already has "everything",
| including py2app.
Perhaps I wasn't clear. I don't add *any* dependencies except those that
~ come with the application itself: i.e. I simply copy the directory
structure of the application (wxGlade, Pears, what have you) into the
app bundle. Any external libraries such as wxPython have to be installed
separately by the end user.
|
| Since you were unwilling to even post the results of my suggestion
| yesterday, implicating me in "neither he nor I could figure out..." is a
| bad way to put it.  Basically, you haven't yet done anything beyond your
| initial message to help me figure it out, and are throwing your hands up
| because I didn't immediately know what kind of craziness is involved in
| Eric3 and how that affects py2app off the top of my head.
Yes, you're right, and I apologize for my tone there. Please attribute
that to a hastily scribbled e-mail. Here's what I should have said:
"The build died. Bob gave me a few suggestions to try, none of which I
was able to make work. I contacted the developer of Eric3 to find out
what module was missing, and he said it was specifically part of Eric3.
~ I haven't had time to drill more deeply into how to this module
integrated into the build."
|
| That said, the way to solve this problem is to create a setup.py and
| tweak the includes option until the application has everything it
| needs.  Write down which modules you had to add, and then figure out why
| the heck they were missing.  If it turns out that this happened due to
| something in PyQt, not the application, then I can make py2app
| automatically work around whatever stupid import trick caused this to
| fail for PyQt from the recipe that currently deals with other
| sip-specific garbage.
OK. This is what I will do--when I have a bit more time. Going through
that effort will get me better acquainted with py2app.
|
|
| py2app is a better choice than BuildApplet for PyOxide.  Adding support
| for BuildApplet before or in addition to py2app seems backwards.  Adding
| support for alias mode is definitely important for something like
| PyOxide, which would suit your use case (aside from machine
| portability), and machine portability with a stupid bundle isn't really
| very useful or important, as I mentioned above.
|
| Perhaps in the future py2app will have a mode similar to alias mode that
| makes the stupidest dependency-free "self-contained" bundle that could
| possibly work (locally), but I am still unconvinced that this is more
| useful than dangerous and confusing.
|
| -bob
|
If "save as applet" from PythonIDE is as non-portable as you say, I'm
curious why I haven't gotten any bug reports on the apps I've built that
way. I do try to make the external dependencies (MacPython add-ons,
wxPython, Tk, PyQt) explicit, and I do provide links for folks to
download and install them. Perhaps that's the reason?
Kevin
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (Darwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFB0voUJmdQs+6YVcoRAg9nAJ9Elktb7TZU/+r9RbtoBdIpQVeuJACfVRkI
k16ThhWMPH9VUZdph3Ye4Dk=
=JTEZ
-END PGP SIGNATURE-
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] Kodos

[Charles Hartman]

Yes please! With Bob Ippolito's helpful pointer (the QPL is **not** 
easily evident on the Troll web site) I now have the free version of 
PyQt, though I haven't tested it yet. I'd love to see Kodos. On the 
SourceForge.net page?

Charles Hartman
Professor of English, Poet in Residence
http://cherry.conncoll.edu/cohar
http://villex.blogspot.com
On Dec 29, 2004, at 10:31 AM, Kevin Walzer wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I have a working app bundle of Kodos put together...I haven't released
it because I wasn't sure anyone would be interested in it, but it works
fine with my PyQt-Mac distribution. Let me know if you'd like me to 
post
it for download.

- --
Cheers,
Kevin Walzer, PhD
WordTech Software--Open Source Applications and Packages for OS X
http://www.wordtech-software.com
http://www.smallbizmac.com
http://www.kevin-walzer.com
mailto:[EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (Darwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFB0s3hJmdQs+6YVcoRAvIuAJ4+4G31sPmDM0Z/ufrul0u3w1Lc3wCghgt8
3mlrb6FLlqehCL73pQh4FGQ=
=LlBW
-END PGP SIGNATURE-
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] BuildApplet in next distro of MacPython?

[Charles Hartman]

Please not PyOxide. I used it for a while, I like it -- but it doesn't 
work, and it hasn't been worked on or updated in months. The current 
PythonIDE is minimal and shabby, but it works just fine.

Charles Hartman
Professor of English, Poet in Residence
http://cherry.conncoll.edu/cohar
http://villex.blogspot.com
On Dec 29, 2004, at 11:58 AM, Kevin Walzer wrote:
I'm curious about whether BuildApplet and PythonIDE will be included in
the next iteration of MacPython, or whether these will be replaced by
py2app and PyOxide. Although I know these are old technologies,
especially BuildApplet, I'd like to request that they be retained, even
if they're not updated or enhanced.
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] Kodos

[Charles Hartman]

Yes please! With Bob Ippolito's helpful pointer (the QPL is **not**
easily evident on the Troll web site) I now have the free version of
PyQt, though I haven't tested it yet. I'd love to see Kodos. On the
SourceForge.net page?
Charles Hartman
Professor of English, Poet in Residence
http://cherry.conncoll.edu/cohar
http://villex.blogspot.com
On Dec 29, 2004, at 10:31 AM, Kevin Walzer wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I have a working app bundle of Kodos put together...I haven't released
it because I wasn't sure anyone would be interested in it, but it works
fine with my PyQt-Mac distribution. Let me know if you'd like me to 
post
it for download.

- --
Cheers,
Kevin Walzer, PhD
WordTech Software--Open Source Applications and Packages for OS X
http://www.wordtech-software.com
http://www.smallbizmac.com
http://www.kevin-walzer.com
mailto:[EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (Darwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFB0s3hJmdQs+6YVcoRAvIuAJ4+4G31sPmDM0Z/ufrul0u3w1Lc3wCghgt8
3mlrb6FLlqehCL73pQh4FGQ=
=LlBW
-END PGP SIGNATURE-
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] BuildApplet in next distro of MacPython?

[Bob Ippolito]

On Dec 29, 2004, at 1:40 PM, Kevin Walzer wrote:
| py2app is a better choice than BuildApplet for PyOxide.  Adding 
support
| for BuildApplet before or in addition to py2app seems backwards.  
Adding
| support for alias mode is definitely important for something like
| PyOxide, which would suit your use case (aside from machine
| portability), and machine portability with a stupid bundle isn't 
really
| very useful or important, as I mentioned above.
|
| Perhaps in the future py2app will have a mode similar to alias mode 
that
| makes the stupidest dependency-free "self-contained" bundle that 
could
| possibly work (locally), but I am still unconvinced that this is more
| useful than dangerous and confusing.

If "save as applet" from PythonIDE is as non-portable as you say, I'm
curious why I haven't gotten any bug reports on the apps I've built 
that
way. I do try to make the external dependencies (MacPython add-ons,
wxPython, Tk, PyQt) explicit, and I do provide links for folks to
download and install them. Perhaps that's the reason?
I said that py2app's alias mode is non-portable.  BuildApplet creates 
portable applications that work if all dependencies are expected to 
already be installed.  You probably haven't received bug reports 
because you have an audience of developers who are used to and willing 
to install all these dependencies.  Pointing them all out probably 
helps, too.

-bob
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] BuildApplet in next distro of MacPython?

[Kevin Walzer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Bob Ippolito wrote:
|
| I said that py2app's alias mode is non-portable.  BuildApplet creates
| portable applications that work if all dependencies are expected to
| already be installed.
Hmmm. That's a good argument to retain BuildApplet in some form.
You probably haven't received bug reports because
| you have an audience of developers who are used to and willing to
| install all these dependencies.
You're probably right.
I will defintely be working more deeply with py2app because I'm planning
to rewrite one or more of my AppleScript Studio applications in Python.
Even though those will be open-source applications, they will be
targeted at end users, and I will definitely want to create truly
portable standalone apps with py2app.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (Darwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFB0yHRJmdQs+6YVcoRAl28AJ9dEsA13g/VW8fAoeDF1/OoelAepQCfZ/3o
MqgX5NIMqrdav26xBJybQdw=
=KnkD
-END PGP SIGNATURE-
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] BuildApplet in next distro of MacPython?

[Bob Ippolito]

On Dec 29, 2004, at 4:29 PM, Kevin Walzer wrote:
Bob Ippolito wrote:
| I said that py2app's alias mode is non-portable.  BuildApplet creates
| portable applications that work if all dependencies are expected to
| already be installed.
Hmmm. That's a good argument to retain BuildApplet in some form.
Not really, if anything else, it is an argument to add a "stupid" mode 
to py2app.  However, as I've said before, I'm hesitant to prioritize 
that since its usage is limited to two targets:  very controlled 
environments, and python software developers.

In both cases, it's currently possible and likely better to specify 
your expected environment by exclusion.  In other words, add an exclude 
for each module/package you expect the user to already have.  This is 
counter to the "ease of use" of BuildApplet, but given how uncommon 
this use case is, how hard it is to test a BuildApplet application for 
dependencies (you need two machines), I'd rather leave it as-is for a 
while because people distributing applications built in this style 
should at least know what their dependencies are.  In your case, you 
already have to know the definitive list of requirements for 
documentation purposes, so it's not hard to move that down to the 
setup.py as excludes.

Back to the original problem, you said that these XML modules are 
specific to Eric3, which means that somewhere along the way Eric3 is 
doing some non-statement imports or exercising some bug in py2app 
0.1.6.  Try it again with py2app 0.1.7, which was soft launched earlier 
today in expectation of a PyObjC 1.2 release later today or tomorrow 
morning (when I've built+tested the Jaguar package).  If that doesn't 
work, I'll take a look at Eric3 myself to see what's going on and 
either provide a workaround or compensate for what's going on in py2app 
0.1.8.

-bob
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] BuildApplet in next distro of MacPython?

[gandreas]

On Dec 29, 2004, at 2:51 PM, Charles Hartman wrote:
Please not PyOxide. I used it for a while, I like it -- but it doesn't 
work, and it hasn't been worked on or updated in months. The current 
PythonIDE is minimal and shabby, but it works just fine.


Actually, it has been worked on, but there isn't anything significant 
yet (OK, so the last release was in the beginning of October, that 
hardly means it's not being worked on or updated - after all, this all 
needs to be done in my limited free time).

And I've used it on three different computer and works reasonably well 
on all of them - where are you seeing problems?  What exactly happens, 
etc...?  I can't fix what I don't know about.

Don't forget - the source is fully available, so you can always work on 
it yourself and submit fixes, etc...

But back on topic (sort of) - I plan to continue to support 
BundleBuilder (in as much as it is currently supported), but I do plan 
to add support for py2app.  No further work on bundle builder will be 
done, however, since the future is py2app (though feel free to submit 
patches on it).


Glenn Andreas  [EMAIL PROTECTED]
  oh my!
Mad, Bad, and Dangerous to Know
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] BuildApplet in next distro of MacPython?

[Kevin Walzer]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
|
| Back to the original problem, you said that these XML modules are
| specific to Eric3, which means that somewhere along the way Eric3 is
| doing some non-statement imports or exercising some bug in py2app
| 0.1.6.  Try it again with py2app 0.1.7, which was soft launched earlier
| today in expectation of a PyObjC 1.2 release later today or tomorrow
| morning (when I've built+tested the Jaguar package).  If that doesn't
| work, I'll take a look at Eric3 myself to see what's going on and either
| provide a workaround or compensate for what's going on in py2app 0.1.8.
|
| -bob
|
I installed 0.1.7 and gave it a try on the stable version (3.4.2) of
Eric3 that I'm shipping with my PyQt-distro. Everything built
flawlessly, reflecting the support you've added for PyQt.
The version of Eric3 that has been giving me problems across the board,
including with py2app, is 3.5.1. It's buggy and crashes whenever I'm
trying to save files. I have no idea why it does this, especially since
I have all the current dependencies built and installed correctly. There
was a bug in Qt 3.3.2 that caused problems with QScintilla, but that was
fixed for 3.3.3.
The problems with 3.5.1 were still there with the new version of py2app.
So, I'm convinced the issue is the new version of Eric, and it's so
buggy in general that I wouldn't waste any further time trying to tweak
py2app to work with it.
I'm waiting for the release of Qt 4 early next year, and then the
follow-up releases of PyQt. At that point I'll revisit Eric3.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.4 (Darwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFB0zL5JmdQs+6YVcoRAvydAJ4giO54ljDyhydnk55hskxw2McQowCcDXkW
6M7/RbUqXGzvq21Ucgns6Ng=
=blN+
-END PGP SIGNATURE-
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] How badly is _locale broken?

[Jack Jansen]

On 29-dec-04, at 11:32, Ronald Oussoren wrote:
I know that. But not linking with CoreServices should fix _locale for 
python scripts that don't use mac-specific features.
If I understand correctly it's the loading of CoreServices that causes 
the _locale problem, right? If that's indeed the case then I think not 
linking with CoreServices would make this problem even worse: imagine a 
scenario where an unsuspecting user has working code in a toy app, but 
it fails when used in his GUI app (which happens to use CoreServices). 
Or code that works standalone but not in .
--
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  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] How badly is _locale broken?

[Bob Ippolito]

On Dec 29, 2004, at 6:06 PM, Jack Jansen wrote:
On 29-dec-04, at 11:32, Ronald Oussoren wrote:
I know that. But not linking with CoreServices should fix _locale for 
python scripts that don't use mac-specific features.
If I understand correctly it's the loading of CoreServices that causes 
the _locale problem, right? If that's indeed the case then I think not 
linking with CoreServices would make this problem even worse: imagine 
a scenario where an unsuspecting user has working code in a toy app, 
but it fails when used in his GUI app (which happens to use 
CoreServices). Or code that works standalone but not in .
IIRC it's the CoreFoundation loader that abuses some private 
functionality that forces the C locale.  Simply faulting on any symbol 
in CoreFoundation will cause this loader to run.  I think CoreServices 
uses CoreFoundation, which may have caused the confusion, but I'm 
pretty sure it's a CoreFoundation issue.

Fortunately, the _locale module links to CoreFoundation (directly or 
indirectly) anyway to get the current locale (or something like that).  
The way it does things on current versions of OS X probably doesn't do 
anything useful, but at least it's broken even with the reduced core 
dependencies in Python 2.4.

-bob
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

[Pythonmac-SIG] The PantherPythonFix installer and C++ extensions

[Jack Jansen]

On 29-dec-04, at 11:40, Bob Ippolito wrote:
[Bob notes that my PantherPythonFix installer will break C++ 
compilation because distutils simply replaces the first component of 
LDSHARED with "c++"]
Any suggestions as to what to do to get c++ compilation fixed?
I can think of two ways:
1. Patch distutils to actually do 
os.environ['MACOSX_DEPLOYMENT_TARGET'] = '10.3' because 
CCompiler.spawn doesn't take an environment dict.
2. Patch distutils to skip over environment variables (basically 
change that "0" into something smarter).   This is probably less 
desirable because who knows where this happens, and who knows what 
third party compiler subclasses used this original stupid code as a 
template.
Both of these mean that "the simple installer that just puts a new 
Makefile into lib/python2.3/config" has just gone out the window:-(

I think I have a better alternative to both of these suggestions 
(basically what I just checked in for 2.5a0: allow the Makefile to 
force a setting for MACOSX_DEPLOYMENT_TARGET, unless it was set 
already), but that still leaves the problem that there's more files to 
patch.

We could of course replace sysconfig.py and sysconfig.pyc in place, but 
I don't feel happy about that. (So: please argue that it isn't a 
problem).

Or we could install a newer, patched distutils into 
/Library/Python/2.3. But that has the problem that it'll obliterate any 
other newer distutils the end user may have installed. Also not a good 
idea.

Or maybe someone here has a silver bullet?
--
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  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] BuildApplet in next distro of MacPython?

[Jack Jansen]

On 29-dec-04, at 17:58, Kevin Walzer wrote:
I'm curious about whether BuildApplet and PythonIDE will be included in
the next iteration of MacPython, or whether these will be replaced by
py2app and PyOxide. Although I know these are old technologies,
especially BuildApplet, I'd like to request that they be retained, even
if they're not updated or enhanced.
Just to give the party line on this:
- BuildApplet and PythonIDE will be with us as-is for the MacPython 2.4 
series of releases. They may move into some dark corner when 
replacements are available, but they will be available.
- Like you (and has, if I understand him correctly) I think the minimal 
functionality BuildApplet provides has a place in the grand scheme of 
things. Bob is 100% right in all of his arguments (it doesn't work, it 
can't work, it won't work anywhere else, it'll only work in a very 
limited number of cases, etc etc etc), but BuildApplet has been with us 
for 10 years now and proven it's worth. And what it does was copied 
from "save as applet" in Apple's Script Editor (along with all the 
warts) and that is still going strong after 15 years. So if I have a 
say in things there'll be something as simple as BuildApplet for a long 
time to come:-)
--
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  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

[Pythonmac-SIG] Re: The PantherPythonFix installer and C++ extensions

[Bob Ippolito]

On Dec 29, 2004, at 6:25 PM, Jack Jansen wrote:
On 29-dec-04, at 11:40, Bob Ippolito wrote:
[Bob notes that my PantherPythonFix installer will break C++ 
compilation because distutils simply replaces the first component of 
LDSHARED with "c++"]
Any suggestions as to what to do to get c++ compilation fixed?
I can think of two ways:
1. Patch distutils to actually do 
os.environ['MACOSX_DEPLOYMENT_TARGET'] = '10.3' because 
CCompiler.spawn doesn't take an environment dict.
2. Patch distutils to skip over environment variables (basically 
change that "0" into something smarter).   This is probably less 
desirable because who knows where this happens, and who knows what 
third party compiler subclasses used this original stupid code as a 
template.
Both of these mean that "the simple installer that just puts a new 
Makefile into lib/python2.3/config" has just gone out the window:-(
Yeah.. I'd rather have broken C++ support than broken linker support 
though.. so this patch is better than no patch.

I think I have a better alternative to both of these suggestions 
(basically what I just checked in for 2.5a0: allow the Makefile to 
force a setting for MACOSX_DEPLOYMENT_TARGET, unless it was set 
already), but that still leaves the problem that there's more files to 
patch.

We could of course replace sysconfig.py and sysconfig.pyc in place, 
but I don't feel happy about that. (So: please argue that it isn't a 
problem).
I'm +1 for replacing sysconfig.py.  It's known to be exactly the one 
included with 2.3.0.  The user gets what they deserve if they made 
their own changes to sysconfig.py here.

Or we could install a newer, patched distutils into 
/Library/Python/2.3. But that has the problem that it'll obliterate 
any other newer distutils the end user may have installed. Also not a 
good idea.
-1.. you would also need to use a weird .pth hack to make sure it gets 
into sys.path before stdlib..

-bob
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] Re: Re: [Python-checkins] python/dist/src/Mac/OSX fixapplepython23.py, 1.1, 1.2

[Robert Kern]

Bob Ippolito wrote:
I have no idea, but I remember this issue was brought up at some point 
during one of the many discussions of this issue.  I think it was also 
mentioned that SciPy's distutils extensions (or is it a fork?) does 
something similarly stupid when frobbing in a Fortran compiler.
Extension, and yes it does something similarly stupid.
--
Robert Kern
[EMAIL PROTECTED]
"In the fields of hell where the grass grows high
 Are the graves of dreams allowed to die."
  -- Richard Harter
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] BuildApplet in next distro of MacPython?

[Donovan Preston]

On Dec 29, 2004, at 10:40 AM, Kevin Walzer wrote:
Perhaps I wasn't clear. I don't add *any* dependencies except those 
that
~ come with the application itself: i.e. I simply copy the directory
structure of the application (wxGlade, Pears, what have you) into the
app bundle. Any external libraries such as wxPython have to be 
installed
separately by the end user.
You can just as easily do this with app bundles built by py2app.
dp
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] BuildApplet in next distro of MacPython?

[Bob Ippolito]

On Dec 29, 2004, at 11:48 PM, Donovan Preston wrote:
On Dec 29, 2004, at 10:40 AM, Kevin Walzer wrote:
Perhaps I wasn't clear. I don't add *any* dependencies except those 
that
~ come with the application itself: i.e. I simply copy the directory
structure of the application (wxGlade, Pears, what have you) into the
app bundle. Any external libraries such as wxPython have to be 
installed
separately by the end user.
You can just as easily do this with app bundles built by py2app.
Yeah, if your main script doesn't have any detected dependencies.. or 
they're explicitly excluded.

-bob
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig