[Pythonmac-SIG] Problems installing Numpy using Universal MacPython

[James Boyle]

I posted this to the numpy mailing list - I am re-posting here since it is a more complete description of the situation than my previous post to this list. 

I am running OX 10.3.9. I installed python 2.4.2 using Universal MacPython 2.4.2.dmg.
I am on a PowerPC G4. The Universal build is designed to install on the Mac PPC and Intel machines.

When I run the numpy 0.9.6 install it apparently fails on the configure. The whole trace back is at the end of this posting.
One thing that I noted  was the line:

gcc options: '-arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd -fno-common -dynamic -DNDEBUG -g'

It appears that the configure routines think that I have two architectures - ppc and i386. 
At my low level of understanding, all I can do is speculate that the Universal install generates some confusion as to the actual cpu.
Somewhere numpy is keying on information that is ambiguous in the universal install.

I have installed Numeric, matplotlib and other packages without a problem. 

--Jim


The trace back from >python setup.py build:

Running from numpy source directory.
Warning: not existing path in numpy/distutils: site.cfg
F2PY Version 2_2236
blas_opt_info:
FOUND:
extra_link_args = ['-Wl,-framework', '-Wl,Accelerate']
define_macros = [('NO_ATLAS_INFO', 3)]
extra_compile_args = ['-faltivec', '-I/System/Library/Frameworks/vecLib.framework/Headers']

lapack_opt_info:
FOUND:
extra_link_args = ['-Wl,-framework', '-Wl,Accelerate']
define_macros = [('NO_ATLAS_INFO', 3)]
extra_compile_args = ['-faltivec']

running build
running config_fc
running build_src
building py_modules sources
creating build
creating build/src
creating build/src/numpy
creating build/src/numpy/distutils
building extension "numpy.core.multiarray" sources
creating build/src/numpy/core
Generating build/src/numpy/core/config.h
customize NAGFCompiler
customize AbsoftFCompiler
customize IbmFCompiler
customize GnuFCompiler
customize GnuFCompiler
customize GnuFCompiler using config
gcc options: '-arch ppc -arch i386 -isysroot /Developer/SDKs/MacOSX10.4u.sdk -fno-strict-aliasing -Wno-long-double -no-cpp-precomp -mno-fused-madd -fno-common -dynamic -DNDEBUG -g'
compile options: '-I/Library/Frameworks/Python.framework/Versions/2.4/include/python2.4 -Inumpy/core/src -Inumpy/core/include -I/Library/Frameworks/Python.framework/Versions/2.4/include/python2.4 -c'
gcc: _configtest.c
gcc: cannot specify -o with -c or -S and multiple compilations
gcc: cannot specify -o with -c or -S and multiple compilations
failure.
removing: _configtest.c _configtest.o
Traceback (most recent call last):
File "setup.py", line 76, in ?
setup_package()
File "setup.py", line 69, in setup_package
setup( **config.todict() )
File "/Volumes/IBM1/macPython/numpy-0.9.6/numpy/distutils/core.py", line 85, in setup
return old_setup(**new_attr)
File "/Library/Frameworks/Python.framework/Versions/2.4//lib/python2.4/distutils/core.py", line 149, in setup
dist.run_commands()
File "/Library/Frameworks/Python.framework/Versions/2.4//lib/python2.4/distutils/dist.py", line 946, in run_commands
self.run_command(cmd)
File "/Library/Frameworks/Python.framework/Versions/2.4//lib/python2.4/distutils/dist.py", line 966, in run_command
cmd_obj.run()
File "/Library/Frameworks/Python.framework/Versions/2.4//lib/python2.4/distutils/command/build.py", line 112, in run
self.run_command(cmd_name)
File "/Library/Frameworks/Python.framework/Versions/2.4//lib/python2.4/distutils/cmd.py", line 333, in run_command
self.distribution.run_command(command)
File "/Library/Frameworks/Python.framework/Versions/2.4//lib/python2.4/distutils/dist.py", line 966, in run_command
cmd_obj.run()
File "/Volumes/IBM1/macPython/numpy-0.9.6/numpy/distutils/command/build_src.py", line 84, in run
self.build_sources()
File "/Volumes/IBM1/macPython/numpy-0.9.6/numpy/distutils/command/build_src.py", line 99, in build_sources
self.build_extension_sources(ext)
File "/Volumes/IBM1/macPython/numpy-0.9.6/numpy/distutils/command/build_src.py", line 209, in build_extension_sources
sources = self.generate_sources(sources, ext)
File "/Volumes/IBM1/macPython/numpy-0.9.6/numpy/distutils/command/build_src.py", line 267, in generate_sources
source = func(extension, build_dir)
File "numpy/core/setup.py", line 37, in generate_config_h
raise "ERROR: Failed to test configuration"
ERROR: Failed to test configuration___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] Problems installing Numpy using Universal MacPython

[Ronald Oussoren]

On 27-mrt-2006, at 18:00, James Boyle wrote:

> I posted this to the numpy mailing list - I am re-posting here  
> since it is a more complete description of the situation than my  
> previous post to this list.
>
> I am running OX 10.3.9. I installed python 2.4.2 using Universal  
> MacPython 2.4.2.dmg.
> I am on a PowerPC G4. The Universal build is designed to install on  
> the Mac PPC and Intel machines.
>
> When I run the numpy 0.9.6 install it apparently fails on the  
> configure. The whole trace back is at the end of this posting.
> One thing that I noted  was the line:
>
> gcc options: '-arch ppc -arch i386 -isysroot /Developer/SDKs/ 
> MacOSX10.4u.sdk -fno-strict-aliasing -Wno-long-double -no-cpp- 
> precomp -mno-fused-madd -fno-common -dynamic -DNDEBUG -g'
>
> It appears that the configure routines think that I have two  
> architectures - ppc and i386.
> At my low level of understanding, all I can do is speculate that  
> the Universal install generates some confusion as to the actual cpu.
> Somewhere numpy is keying on information that is ambiguous in the  
> universal install.

The problem is that gcc 3.3 on 10.3.9 doesn't support some of these  
options. Specifcally it doesn't know '-isysroot' and also doesn't  
support the i386 architecture. I'm pretty sure that I had implemented  
support for stripping these arguments on a 10.3 system. Hopefully  
I'll have time to boot into 10.3 tomorrow.

Ronald

>
> I have installed Numeric, matplotlib and other packages without a  
> problem.
>
> --Jim
>
>
> The trace back from >python setup.py build:
>
> Running from numpy source directory.
> Warning: not existing path in numpy/distutils: site.cfg
> F2PY Version 2_2236
> blas_opt_info:
>   FOUND:
> extra_link_args = ['-Wl,-framework', '-Wl,Accelerate']
> define_macros = [('NO_ATLAS_INFO', 3)]
> extra_compile_args = ['-faltivec', '-I/System/Library/ 
> Frameworks/vecLib.framework/Headers']
>
> lapack_opt_info:
>   FOUND:
> extra_link_args = ['-Wl,-framework', '-Wl,Accelerate']
> define_macros = [('NO_ATLAS_INFO', 3)]
> extra_compile_args = ['-faltivec']
>
> running build
> running config_fc
> running build_src
> building py_modules sources
> creating build
> creating build/src
> creating build/src/numpy
> creating build/src/numpy/distutils
> building extension "numpy.core.multiarray" sources
> creating build/src/numpy/core
> Generating build/src/numpy/core/config.h
> customize NAGFCompiler
> customize AbsoftFCompiler
> customize IbmFCompiler
> customize GnuFCompiler
> customize GnuFCompiler
> customize GnuFCompiler using config
> gcc options: '-arch ppc -arch i386 -isysroot /Developer/SDKs/ 
> MacOSX10.4u.sdk -fno-strict-aliasing -Wno-long-double -no-cpp- 
> precomp -mno-fused-madd -fno-common -dynamic -DNDEBUG -g'
> compile options: '-I/Library/Frameworks/Python.framework/Versions/ 
> 2.4/include/python2.4 -Inumpy/core/src -Inumpy/core/include -I/ 
> Library/Frameworks/Python.framework/Versions/2.4/include/python2.4 -c'
> gcc: _configtest.c
> gcc: cannot specify -o with -c or -S and multiple compilations
> gcc: cannot specify -o with -c or -S and multiple compilations
> failure.
> removing: _configtest.c _configtest.o
> Traceback (most recent call last):
>   File "setup.py", line 76, in ?
> setup_package()
>   File "setup.py", line 69, in setup_package
> setup( **config.todict() )
>   File "/Volumes/IBM1/macPython/numpy-0.9.6/numpy/distutils/ 
> core.py", line 85, in setup
> return old_setup(**new_attr)
>   File "/Library/Frameworks/Python.framework/Versions/2.4//lib/ 
> python2.4/distutils/core.py", line 149, in setup
> dist.run_commands()
>   File "/Library/Frameworks/Python.framework/Versions/2.4//lib/ 
> python2.4/distutils/dist.py", line 946, in run_commands
> self.run_command(cmd)
>   File "/Library/Frameworks/Python.framework/Versions/2.4//lib/ 
> python2.4/distutils/dist.py", line 966, in run_command
> cmd_obj.run()
>   File "/Library/Frameworks/Python.framework/Versions/2.4//lib/ 
> python2.4/distutils/command/build.py", line 112, in run
> self.run_command(cmd_name)
>   File "/Library/Frameworks/Python.framework/Versions/2.4//lib/ 
> python2.4/distutils/cmd.py", line 333, in run_command
> self.distribution.run_command(command)
>   File "/Library/Frameworks/Python.framework/Versions/2.4//lib/ 
> python2.4/distutils/dist.py", line 966, in run_command
> cmd_obj.run()
>   File "/Volumes/IBM1/macPython/numpy-0.9.6/numpy/distutils/command/ 
> build_src.py", line 84, in run
> self.build_sources()
>   File "/Volumes/IBM1/macPython/numpy-0.9.6/numpy/distutils/command/ 
> build_src.py", line 99, in build_sources
> self.build_extension_sources(ext)
>   File "/Volumes/IBM1/macPython/numpy-0.9.6/numpy/distutils/command/ 
> build_src.py", line 209, in build_extension_sources
> sources = self.generate_sources(sources, ext)
>   File "/Volumes/IBM1/macPython/numpy-0.9.6/numpy/distutils/command/ 
> build_src.py", line 267, in generate_sou

Re: [Pythonmac-SIG] Problems installing Numpy using Universal MacPython

[Robert Kern]

Ronald Oussoren wrote:
> On 27-mrt-2006, at 18:00, James Boyle wrote:
> 
> 
>>I posted this to the numpy mailing list - I am re-posting here  
>>since it is a more complete description of the situation than my  
>>previous post to this list.
>>
>>I am running OX 10.3.9. I installed python 2.4.2 using Universal  
>>MacPython 2.4.2.dmg.
>>I am on a PowerPC G4. The Universal build is designed to install on  
>>the Mac PPC and Intel machines.
>>
>>When I run the numpy 0.9.6 install it apparently fails on the  
>>configure. The whole trace back is at the end of this posting.
>>One thing that I noted  was the line:
>>
>>gcc options: '-arch ppc -arch i386 -isysroot /Developer/SDKs/ 
>>MacOSX10.4u.sdk -fno-strict-aliasing -Wno-long-double -no-cpp- 
>>precomp -mno-fused-madd -fno-common -dynamic -DNDEBUG -g'
>>
>>It appears that the configure routines think that I have two  
>>architectures - ppc and i386.
>>At my low level of understanding, all I can do is speculate that  
>>the Universal install generates some confusion as to the actual cpu.
>>Somewhere numpy is keying on information that is ambiguous in the  
>>universal install.
> 
> The problem is that gcc 3.3 on 10.3.9 doesn't support some of these  
> options. Specifcally it doesn't know '-isysroot' and also doesn't  
> support the i386 architecture. I'm pretty sure that I had implemented  
> support for stripping these arguments on a 10.3 system. Hopefully  
> I'll have time to boot into 10.3 tomorrow.

numpy extends distutils, so it may be overriding certain changes you've made to
distutils. We may have to duplicate those changes in numpy.distutils.

-- 
Robert Kern
[EMAIL PROTECTED]

"I have come to believe that the whole world is an enigma, a harmless enigma
 that is made terrible by our own mad attempt to interpret it as though it had
 an underlying truth."
  -- Umberto Eco
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

[Pythonmac-SIG] Python 2.4.3c1 universal binaries

[Ronald Oussoren]

I have a universal build of the Python 2.4.3c1 release in the public  
folder of my idisk (at http://homepage.mac.com/ronaldoussoren). This  
passes the unittests on OSX 10.4 (both intel and ppc). I haven't  
tested it with 10.3.9 yet.

This also solves the problems Nicolas Cole was having w.r.t. resizing  
terminals and curses applications. This is because this build  
includes it's own version of the curses library that don't suffer  
from the bug in Apple's build. Hopefully this also means that the  
curses module works on 10.3.9.

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

Re: [Pythonmac-SIG] Installing numpy 0.9.6 problems

[Christopher Barker]

Ronald Oussoren wrote:

> I'd prefer to have 1 installer for python on OSX, that makes support  
> a lot easier.

And we would like to by able to use Py2App to build apps that will run 
under both 10.3.9 and 10.4.*

-Chris




-- 
Christopher Barker, Ph.D.
Oceanographer

NOAA/OR&R/HAZMAT (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] [ann] Appscript Installer 1.3 released

[Christopher Barker]

Ronald Oussoren wrote:

> wxPython definitely works, I've tested it. That is, if you are on
> a PPC box. The existing wxPython binary installer installs a PPC binary,
> that won't work with a universal build on intel.

That's good to know,but we really do need to get a Universal build of 
wxPython (and lots of other stuff!) built. It looks like it will beg a 
bit of a project, and it doesn't look like any of the people who really 
know what they are doing (Kevin O, Robin, ??? )have the time and/or 
tools for it now.

I'm going to give a try this week myself. Prepare yourselves for questions!

I'm also going to take this to mean that, in general, all the packages 
built for the 2.4.1 Framework build should work with the Universal build 
On PPC.

Users of the Intel machines are probably still better off using the 
2.4.1 PPC build and related packages, and it will all run under Rosetta.

> Feel free to provide universal packages, and tell us about software that
> doesn't work with universal python.

I'll be working on that this week. I don't have an Intel box to test on 
at the moment, but should be getting one soon.

> Even a wishlist for packages would be useful. 

wxPython
numpy
Numeric
numarray
matplotlib
PIL

I can work on all of those.

Then:
PyGTK : Is there a version that can work entirely fink (or darwinports) 
free?
PyQT: that's going to be fun!

-Chris



-- 
Christopher Barker, Ph.D.
Oceanographer

NOAA/OR&R/HAZMAT (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] [ann] Appscript Installer 1.3 released

[Bill Janssen]

I've added a link in the Wiki page about alternate distribution
pointing to Ronald's 2.4.2 installer.

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

[Pythonmac-SIG] Marking the pre-built extensions as Intel-capable...

[Bill Janssen]

I'm looking over the downloads page again, thinking about what we need
to do to support the Universal builds.

First off, the discussion last week about which packages will work
with it seems very important.

Who's got edit access to pythonmac.org?

Could someone please put a note on http://pythonmac.org/packages/ to
say that the packages listed there are all PPC-only?

And do we need a new section for 10.4.2-capable packages, maybe with a
stamp that marks those that are Intel-capable?

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

Re: [Pythonmac-SIG] Marking the pre-built extensions as Intel-capable...

[Bob Ippolito]

On Mar 27, 2006, at 11:36 AM, Bill Janssen wrote:

> I'm looking over the downloads page again, thinking about what we need
> to do to support the Universal builds.
>
> First off, the discussion last week about which packages will work
> with it seems very important.
>
> Who's got edit access to pythonmac.org?

Just me, but I'm willing to dole out access to anyone who will commit  
to doing something with those privileges :)

> Could someone please put a note on http://pythonmac.org/packages/ to
> say that the packages listed there are all PPC-only?

Done

> And do we need a new section for 10.4.2-capable packages, maybe with a
> stamp that marks those that are Intel-capable?

That whole section really needs to be restructured to address the  
common questions and issues people have regarding finding the right  
packages for them.  I think I'd like to turn http://pythonmac.org/ 
packages/ into just a launch pad for finding a list of packages for  
the Python that you're interested in.

-bob

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

Re: [Pythonmac-SIG] Marking the pre-built extensions as Intel-capable...

[Christopher Barker]

Bob Ippolito wrote:

> That whole section really needs to be restructured to address the  
> common questions and issues people have regarding finding the right  
> packages for them.

great idea.

> I think I'd like to turn http://pythonmac.org/ 
> packages/ into just a launch pad for finding a list of packages for  
> the Python that you're interested in.

Do you mean that it wouldn't actually host them for download there?

Please no. I think it is a VERY good idea to have a collection there for 
download. Pretty soon, I think we'll be able to call the 2.4.3 Universal 
build the "officially recommended" build, and we can have a collection 
of packages there for it. I now I'll contribute a few, and I'm sure 
others will as well.

One question is: should they be eggs or traditional *.mpkgs?

-Chris


-- 
Christopher Barker, Ph.D.
Oceanographer

NOAA/OR&R/HAZMAT (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] Marking the pre-built extensions as Intel-capable...

[Bob Ippolito]

On Mar 27, 2006, at 2:55 PM, Christopher Barker wrote:

> Bob Ippolito wrote:
>
>> That whole section really needs to be restructured to address the
>> common questions and issues people have regarding finding the right
>> packages for them.
>
> great idea.
>
>> I think I'd like to turn http://pythonmac.org/
>> packages/ into just a launch pad for finding a list of packages for
>> the Python that you're interested in.
>
> Do you mean that it wouldn't actually host them for download there?

No, I mean that that URL won't directly list any packages.  It'll be  
a listing of package lists and enough information to direct a newish  
user to the right list.

> Please no. I think it is a VERY good idea to have a collection  
> there for
> download. Pretty soon, I think we'll be able to call the 2.4.3  
> Universal
> build the "officially recommended" build, and we can have a collection
> of packages there for it. I now I'll contribute a few, and I'm sure
> others will as well.
>
> One question is: should they be eggs or traditional *.mpkgs?

I'd certainly prefer eggs where possible, but transitionally we're  
definitely going to need *.mpkgs.  Maybe both for now, and/or  
separate pages for .mpkgs and binary eggs?

-bob

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

Re: [Pythonmac-SIG] Marking the pre-built extensions as Intel-capable...

[Christopher Barker]

Bob Ippolito wrote:

> No, I mean that that URL won't directly list any packages.  It'll be a 
> listing of package lists and enough information to direct a newish user 
> to the right list.

Then yes, that's a great idea. I am, as we e-speak, reworking those 
pages with a different structure now. I'm no web designer, but it should 
give us something that someone can make prettieer if they want.

> I'd certainly prefer eggs where possible, but transitionally we're 
> definitely going to need *.mpkgs.  Maybe both for now, and/or separate 
> pages for .mpkgs and binary eggs?

What happens if you double-click on a *.egg?

I like that anyone with OS-X can figure out how to install from a *.mpkg

-Chris


-- 
Christopher Barker, Ph.D.
Oceanographer

NOAA/OR&R/HAZMAT (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] Marking the pre-built extensions as Intel-capable...

[Nicholas Riley]

On Mon, Mar 27, 2006 at 04:00:07PM -0800, Christopher Barker wrote:
> What happens if you double-click on a *.egg?

That'd be an incredibly cool utility to have, and a lot easier to
write than something like PackageManager.

-- 
Nicholas Riley <[EMAIL PROTECTED]> | 
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] Pythonmac-SIG Digest, Vol 35, Issue 51

[daniel]

>From: Christopher Barker <[EMAIL PROTECTED]>
>To: pythonmac-sig@python.org
>Subject: Re: [Pythonmac-SIG] Installing numpy 0.9.6 problems
>Date: Mon, 27 Mar 2006 09:50:33 -0800

>Ronald Oussoren wrote:

>> I'd prefer to have 1 installer for python on OSX, that makes 
>> support  a lot easier.

>And we would like to by able to use Py2App to build apps that will 
>run under both 10.3.9 and 10.4.*

>-Chris

But shouldn't we be able to build -ppc, -i386, and even -ppc64 with gcc 4.0 and 
then use 'lipo' to paste them to together and let the loader sort them out at 
run-time? Does the loader on 10.3 know enough to pick '-arch ppc' even with 
other in there or am I assuming too much? I'd test it myself, but my G5 1.8 
Dual has died and my Quad hasn't arrived yet since I am out of town for the 
week ;-(.

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

Re: [Pythonmac-SIG] Marking the pre-built extensions as Intel-capable...

[Bill Janssen]

> > Could someone please put a note on http://pythonmac.org/packages/ to
> > say that the packages listed there are all PPC-only?
> 
> Done

Looks good, thanks.

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

[Pythonmac-SIG] The Universal Buld and py2app

[Christopher Barker]

Bob,

What's the status of Py2App and the new universal build. I'd like to 
start making packages for it, but I"d really like bdist_mpkg.

Or should I figure out how to make binary eggs instead?

By the way, is it possible to have the new universal build co-exist with 
the 2.4.1 framework build? At the moment, everything seems to be 
working, at least on my PPC machine, but it makes me a bit nervous to 
just write over what I've got working.

A clarification for others:

AFAICT, on a PPC Mac, the new universal build can be used with old, PC 
only, packages for 2.4.1. This means that for those of us on PPC 
machine, we can have all the old packages while we test and build new ones.

Very cool.

-Chris






-- 
Christopher Barker, Ph.D.
Oceanographer

NOAA/OR&R/HAZMAT (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] Marking the pre-built extensions as Intel-capable...

[Bill Janssen]

> > I'd certainly prefer eggs where possible, but transitionally we're 
> > definitely going to need *.mpkgs.  Maybe both for now, and/or separate 
> > pages for .mpkgs and binary eggs?
> 
> What happens if you double-click on a *.egg?
> 
> I like that anyone with OS-X can figure out how to install from a *.mpkg

Without any experience with "eggs" (I believe that they are another
Phillip Eby brainstorm?), can I suggest that a standard command-line
way of simply wrapping an egg as an mpkg would be a "good thing to
have"?  That way, contributors could just build eggs, and the website
could serve up either a raw egg or a wrapped egg as an mpkg.

Is there a specification for the "egg" format?

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

Re: [Pythonmac-SIG] The Universal Buld and py2app

[Bob Ippolito]

On Mar 27, 2006, at 5:10 PM, Christopher Barker wrote:

> Bob,
>
> What's the status of Py2App and the new universal build. I'd like  
> to start making packages for it, but I"d really like bdist_mpkg.

Not Yet.  I have some patches I need to integrate and test.  I'll try  
and get to it this weekend, maybe sooner.

> Or should I figure out how to make binary eggs instead?

That's what works now on universal.

> By the way, is it possible to have the new universal build co-exist  
> with the 2.4.1 framework build? At the moment, everything seems to  
> be working, at least on my PPC machine, but it makes me a bit  
> nervous to just write over what I've got working.

No, they don't coexist.  They install to the same spot.

> A clarification for others:
>
> AFAICT, on a PPC Mac, the new universal build can be used with old,  
> PC only, packages for 2.4.1. This means that for those of us on PPC  
> machine, we can have all the old packages while we test and build  
> new ones.
>
> Very cool.

That's correct.

-bob

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

Re: [Pythonmac-SIG] Marking the pre-built extensions as Intel-capable...

[Bob Ippolito]

On Mar 27, 2006, at 4:57 PM, Christopher Barker wrote:

> Christopher Barker wrote:
>
>> Then yes, that's a great idea. I am, as we e-speak, reworking  
>> those pages with a different structure now. I'm no web designer,  
>> but it should give us something that someone can make prettier if  
>> they want.
>
> First I added a link to the packages page at the top of the main  
> pythonmac.org page.
>
> I've enclosed a simple rearrangement of the pythonmac.org/packages  
> page. What I've done is create a separate page for each supported  
> build. As the packages built for 10.3 will also work on 10.4, I  
> double listed them, so that a 10.4 user could just go to that page,  
> and see everything that they can use.
>
> I also put a link in  to download the python builds themselves, why  
> not be able to get it all from one place?
>
> Ultimately, we really should have some little semi-automated tool  
> that would make it easy to add a new package to the list, updated  
> the page. For now, doing by hand is not too big a deal, and I  
> don't' want to mess with tools before we settle on a page layout.
>
> The pages are enclosed as a zip file. Ii hope anyone who is  
> interested will give feedback.

Cool, I'll take a look at this probably tomorrow.  The package list  
is currently automated using a dumb little script.. check this:
# the input data
http://pythonmac.org/packages/packages.txt
# the script
http://undefined.org/python/packages.py.txt

-bob


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

Re: [Pythonmac-SIG] Marking the pre-built extensions as Intel-capable...

[Bob Ippolito]

On Mar 27, 2006, at 4:00 PM, Christopher Barker wrote:

> Bob Ippolito wrote:
>
>> No, I mean that that URL won't directly list any packages.  It'll  
>> be a
>> listing of package lists and enough information to direct a newish  
>> user
>> to the right list.
>
> Then yes, that's a great idea. I am, as we e-speak, reworking those
> pages with a different structure now. I'm no web designer, but it  
> should
> give us something that someone can make prettieer if they want.
>
>> I'd certainly prefer eggs where possible, but transitionally we're
>> definitely going to need *.mpkgs.  Maybe both for now, and/or  
>> separate
>> pages for .mpkgs and binary eggs?
>
> What happens if you double-click on a *.egg?

Nothing yet, but it wouldn't be that hard to make a little app that  
associates itself with .egg

> I like that anyone with OS-X can figure out how to install from a  
> *.mpkg

Sure.  Ideally bdist_mpkg will produce *.mpkg installers that just  
contain eggs (for bootstrapping maybe), but that's not currently the  
case.

-bob

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

Re: [Pythonmac-SIG] Pythonmac-SIG Digest, Vol 35, Issue 51

[Bob Ippolito]

On Mar 27, 2006, at 5:10 PM, [EMAIL PROTECTED] wrote:

>> From: Christopher Barker <[EMAIL PROTECTED]>
>> To: pythonmac-sig@python.org
>> Subject: Re: [Pythonmac-SIG] Installing numpy 0.9.6 problems
>> Date: Mon, 27 Mar 2006 09:50:33 -0800
>
>> Ronald Oussoren wrote:
>
>>> I'd prefer to have 1 installer for python on OSX, that makes
>>> support  a lot easier.
>
>> And we would like to by able to use Py2App to build apps that will
>> run under both 10.3.9 and 10.4.*

That will work as long as the apps don't include anything that  
strongly links to 10.4 specific features (e.g. xattr).  We've taken  
steps to make sure that the right thing happens with Python itself,  
but the onus is on third party extensions to also do the right thing  
when relevant.  For most libraries, there shouldn't be an issue.

> But shouldn't we be able to build -ppc, -i386, and even -ppc64 with  
> gcc 4.0 and then use 'lipo' to paste them to together and let the  
> loader sort them out at run-time? Does the loader on 10.3 know  
> enough to pick '-arch ppc' even with other in there or am I  
> assuming too much? I'd test it myself, but my G5 1.8 Dual has died  
> and my Quad hasn't arrived yet since I am out of town for the  
> week ;-(.

ppc64 is definitely not going to work.  You'd need a vanilla unix  
build with no Mac specific stuff to do ppc64, because it only really  
can talk to libSystem.

I don't know what you're talking about with regard to "loader".  If  
you're asking whether 10.3 can run universal binaries, then sure --  
Mac OS X has always had support for fat mach-o files, it's just the  
toolchain that's changed such that you can reasonably make them now.

-bob

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

Re: [Pythonmac-SIG] Marking the pre-built extensions as Intel-capable...

[Bob Ippolito]

On Mar 27, 2006, at 5:13 PM, Bill Janssen wrote:

>>> I'd certainly prefer eggs where possible, but transitionally we're
>>> definitely going to need *.mpkgs.  Maybe both for now, and/or  
>>> separate
>>> pages for .mpkgs and binary eggs?
>>
>> What happens if you double-click on a *.egg?
>>
>> I like that anyone with OS-X can figure out how to install from a  
>> *.mpkg
>
> Without any experience with "eggs" (I believe that they are another
> Phillip Eby brainstorm?), can I suggest that a standard command-line
> way of simply wrapping an egg as an mpkg would be a "good thing to
> have"?  That way, contributors could just build eggs, and the website
> could serve up either a raw egg or a wrapped egg as an mpkg.
>
> Is there a specification for the "egg" format?

http://peak.telecommunity.com/DevCenter/PythonEggs
http://peak.telecommunity.com/DevCenter/EasyInstall
http://peak.telecommunity.com/DevCenter/PkgResources
http://peak.telecommunity.com/DevCenter/setuptools

-bob

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

Re: [Pythonmac-SIG] Marking the pre-built extensions as Intel-capable...

[Alex Martelli]

> Without any experience with "eggs" (I believe that they are another
> Phillip Eby brainstorm?), can I suggest that a standard command-line

Yep, they are.

> Is there a specification for the "egg" format?

http://peak.telecommunity.com/DevCenter/PythonEggs

They're zipfiles containing additional metadata, though it's hard to
find all details and formalspecs on the site...


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

Re: [Pythonmac-SIG] Pythonmac-SIG Digest, Vol 35, Issue 51

[Ronald Oussoren]

On 28-mrt-2006, at 3:10, [EMAIL PROTECTED] wrote:

>> From: Christopher Barker <[EMAIL PROTECTED]>
>> To: pythonmac-sig@python.org
>> Subject: Re: [Pythonmac-SIG] Installing numpy 0.9.6 problems
>> Date: Mon, 27 Mar 2006 09:50:33 -0800
>
>> Ronald Oussoren wrote:
>
>>> I'd prefer to have 1 installer for python on OSX, that makes
>>> support  a lot easier.
>
>> And we would like to by able to use Py2App to build apps that will
>> run under both 10.3.9 and 10.4.*
>
>> -Chris
>
> But shouldn't we be able to build -ppc, -i386, and even -ppc64 with  
> gcc 4.0 and then use 'lipo' to paste them to together and let the  
> loader sort them out at run-time? Does the loader on 10.3 know  
> enough to pick '-arch ppc' even with other in there or am I  
> assuming too much? I'd test it myself, but my G5 1.8 Dual has died  
> and my Quad hasn't arrived yet since I am out of town for the  
> week ;-(.

Sigh, the universal python build already runs on 10.3.9 and supports  
ppc and i386. I don't have a PPC64 box so cannot even try to support  
this. Supporting this in the main build would also require more  
special casing because ppc64 processes can only use a small part of  
the OSX ABI.

Ronald

>
> Daniel
> ___
> 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] Marking the pre-built extensions as Intel-capable...

[Ronald Oussoren]

On 28-mrt-2006, at 3:01, Nicholas Riley wrote:

> On Mon, Mar 27, 2006 at 04:00:07PM -0800, Christopher Barker wrote:
>> What happens if you double-click on a *.egg?
>
> That'd be an incredibly cool utility to have, and a lot easier to
> write than something like PackageManager.

Before anyone starts coding, what should happen when you double-click
on an egg? I'd say this should bring up a dialog that allows you to
install the egg and possibly set some options. Installation will be done
using easy_install.

Ronald

>
> --  
> Nicholas Riley <[EMAIL PROTECTED]> |  njriley>
> ___
> 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