Re: [Pythonmac-SIG] Marking the pre-built extensions as Intel-capable...
On 28-mrt-2006, at 1:18, Bob Ippolito wrote: > > 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? For casual users it is easier to install mpkgs, hence we'll need mpkgs until someone writes the tool that allows one to double-click on eggs to install them. I'm tempted to do so myself just to avoid packaging stuff twice :-) Mpkgs have another advantage: they allow you to include documentation and examples into the package. None of the existing packages on pythonmac.org (except for pyobjc and possibly py2app) actually use this possibility, therefore I'd say this is not a very important advantage. Ronald ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Pythonmac-SIG Digest, Vol 35, Issue 51
> - Original Message - > From: "Ronald Oussoren" <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Subject: Re: [Pythonmac-SIG] Pythonmac-SIG Digest, Vol 35, Issue 51 > Date: Tue, 28 Mar 2006 09:38:11 +0200 > > 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 Not saying it should, I was just making the point that FAT binaries can be constructed in more than even two ways. So it seems the numpy build is treating the 'arch' flags as command line options that can be logically combined and not as seperate binary build selectors as it should. Sorry for trying to help. I am approriately chastised now. ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Pythonmac-SIG Digest, Vol 35, Issue 51
> - Original Message - > From: "Bob Ippolito" <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Subject: Re: [Pythonmac-SIG] Pythonmac-SIG Digest, Vol 35, Issue 51 > Date: Mon, 27 Mar 2006 17:44:13 -0800 > > > > On Mar 27, 2006, at 5:10 PM, [EMAIL PROTECTED] wrote: > > >> From: Christopher Barker <[EMAIL PROTECTED]> > >> To: [email protected] > >> 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 understand--just making a point that the kernel checks the header of the binary to determine how to have it loaded and by which dynamic linker. May be I am stating the obvious, but that, and not combining then with 'lipo' is my assesment of the incorrect configuration of the numpy build 'recipe' > 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. Well I sacrificed recision for brevity. So...I meant the appropriate dynamic linker for the binary as I mentioned above--I was just trying to be terse. Correct me if I am wrong, but still glossing over some details and simplifying, the kernel checks the header of the binary to determine which dynamic linker to use to load the binary's segments. Then they are loaded/overlayed into the process space according to their type by the appropriate linker/segment loader/thing. 'dylibs' are loaded with the timing of the loading depending upon the binding choice, pre-binding being no longer possible in 10.4 and just-in-time being the recommendation now as I recall. So it's just some drudgery to compile for both formats, use 'lipo' to combine them and we have a universal app. Right? Not trying trivialize the work involved--just stating that I think the tools are there and its possible. Daniel > -bob > ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Pythonmac-SIG Digest, Vol 35, Issue 51
On 28-mrt-2006, at 17:46, [EMAIL PROTECTED] wrote: > >> - Original Message - >> From: "Ronald Oussoren" <[EMAIL PROTECTED]> >> To: [EMAIL PROTECTED] >> Subject: Re: [Pythonmac-SIG] Pythonmac-SIG Digest, Vol 35, Issue 51 >> Date: Tue, 28 Mar 2006 09:38:11 +0200 >> >> 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 > > Not saying it should, I was just making the point that FAT binaries > can be constructed in more than even two ways. So it seems the > numpy build is treating the 'arch' flags as command line options > that can be logically combined and not as seperate binary build > selectors as it should. Sorry for trying to help. I am approriately > chastised now. My previous message was a bit too sharp, I hadn't intended to punish anyone :-) The numpy build can be failing for several reasons: * Using a too old build of universal macpython, early builds didn't support building extensions on 10.3 * My patch for distutils is buggy * numpy's custom distutils code is interfering with my changes If you're using Xcode 2.1 or later on OSX 10.4 you can several -arch flags and binaries will be build for all named architectures. This is very convenient, otherwise we'd have to teach distutils about the compile+lipo dance you mentioned and I don't want to perform the necessary surgery on distutils to get it to do that if I don't have to :-) Ronald ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Marking the pre-built extensions as Intel-capable...
Ronald Oussoren wrote: > 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. That sounds good to me. Does easy-install come with the new Universal build package? Or is a good first step to make a package out of that? I'd like to start populating the world with Universal packages. I see a couple possible routes: 1) wait for Bob to finish Py2App (bdist_mpkg): I think he's indicated he's hoping to get that done this weekend. 2) build *.eggs, and hope someone comes up with a app to associate them with later. (and it the meantime they can be installed with the command line easy-install 3) just build them for myself, and wait until this settles out some more. Maybe start a Wiki page with a list of packages and an indication of what was needed to do to build them. -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 - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Marking the pre-built extensions as Intel-capable...
Ronald Oussoren wrote: > For casual users it is easier to install mpkgs, hence we'll need > mpkgs until someone writes the tool that allows one to double-click > on eggs to install them. I'm tempted to do so myself just to avoid > packaging stuff twice :-) > > Mpkgs have another advantage: they allow you to include documentation > and examples into the package. None of the existing packages on > pythonmac.org > (except for pyobjc and possibly py2app) actually use this possibility, > therefore I'd say this is not a very important advantage. Doesn't the wxPython package? Anyway, another advantage of eggs is that they can be versioned, so that users can have different versions of a package installed at once. Couldn't we put a *.egg into a *.mpkg? and get the best of both worlds? -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 - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Marking the pre-built extensions as Intel-capable...
On 28-mrt-2006, at 18:26, Christopher Barker wrote: > Ronald Oussoren wrote: > >> For casual users it is easier to install mpkgs, hence we'll need >> mpkgs until someone writes the tool that allows one to double-click >> on eggs to install them. I'm tempted to do so myself just to avoid >> packaging stuff twice :-) >> >> Mpkgs have another advantage: they allow you to include documentation >> and examples into the package. None of the existing packages on >> pythonmac.org >> (except for pyobjc and possibly py2app) actually use this >> possibility, >> therefore I'd say this is not a very important advantage. > > Doesn't the wxPython package? > > Anyway, another advantage of eggs is that they can be versioned, so > that > users can have different versions of a package installed at once. > > Couldn't we put a *.egg into a *.mpkg? and get the best of both > worlds? There's currently two ways to easily build redistributable packages for OSX: the oldest is bdist_mpkg, the newer is bdist_egg. bdist_mpkg is/was part of py2app and includes a script that allows you to build a .mpkg for every python package that includes a setup.py script. bdist_egg is part of setuptools and AFAIK doesn't include a tool for building eggs for python packages that don't support it, but there is an easy way to build them. There is not yet an easy way to place an egg into a .mpkg, although Bob has indicated that he wants to restructure bdist_mpkg to to this. Ronald > > -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 - [email protected] > http://mail.python.org/mailman/listinfo/pythonmac-sig ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Marking the pre-built extensions as Intel-capable...
> Couldn't we put a *.egg into a *.mpkg? and get the best of both worlds? That would be my vote. Bill ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] Marking the pre-built extensions as Intel-capable...
On 28-mrt-2006, at 18:20, Christopher Barker wrote: > Ronald Oussoren wrote: > >> 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. > > That sounds good to me. > > Does easy-install come with the new Universal build package? Or is a > good first step to make a package out of that? > > I'd like to start populating the world with Universal packages. I > see a > couple possible routes: > > 1) wait for Bob to finish Py2App (bdist_mpkg): I think he's indicated > he's hoping to get that done this weekend. > > 2) build *.eggs, and hope someone comes up with a app to associate > them > with later. (and it the meantime they can be installed with the > command > line easy-install > > 3) just build them for myself, and wait until this settles out some > more. Maybe start a Wiki page with a list of packages and an > indication > of what was needed to do to build them. The universal build does not include setuptools. I'd include some bootstrap code in the tool that is associated with .egg files. I'm going to build eggs for all software that I use, with mpkgs for software that doesn't support eggs (like twisted). Ronald > > -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 - [email protected] > http://mail.python.org/mailman/listinfo/pythonmac-sig ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
[Pythonmac-SIG] SQLite & python
Hi, I am totally confused by all the versions and name conflicts of py- sqlite and sqlite not to mention the python version confusion. What I really want to do is use both sqlite version 2 and sqlite version 3 since I have existing sqlite version2 DBs and new CoreData apps that use sqlite version 3. From a version/nomenclature standpoint there is a huge mess eg: py-sqlite works with either sqlite 2 or sqlite 3 and py-sqlite2 works with sqlite version 3. I have been using py-sqlite with sqlite version 2 successfully. First problem I see is that there are two version of Python on my Tiger system: /usr/bin/python version 2.3.5 /usr/local/bin/python version 2.4.1 Second problem: The (Apple) installed version of sqlite3 is 3.0.8.6 py-sqlite 2.1 requires sqlite 3.2.2 py-sqlite 2.0 requires sqlite 3.1 py-sqlite 1.1 requires sqlite 3.x So it seems that py-sqlite 1.1 is the one I need. If I install it my installed py-sqlite that used the python sqlite version 2 gets overwritten, not nice. It also seems to get instaslled in the python 2.3 library, also not nice. If I go to darwin ports it wants to upgrade my python to 2.4.2 first. Does anyone have a solution? All in all the whole Python database (lack of) mess is ridiculous! I know that Guido does not feel that databases have any place in python but I don't get it, why does the "batteries included" not include database support, databases like MySQL, PostgreSQL & SQLite? At this point I am ready to mostly give up on Python after over 10 years of use and evangelizing. Dan ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] SQLite & python
On 3/28/06, Dan Grassi <[EMAIL PROTECTED]> wrote: > Hi, > > I am totally confused by all the versions and name conflicts of py- > sqlite and sqlite not to mention the python version confusion. What > I really want to do is use both sqlite version 2 and sqlite version 3 > since I have existing sqlite version2 DBs and new CoreData apps that > use sqlite version 3. From a version/nomenclature standpoint there > is a huge mess eg: py-sqlite works with either sqlite 2 or sqlite 3 > and py-sqlite2 works with sqlite version 3. > > I have been using py-sqlite with sqlite version 2 successfully. > > First problem I see is that there are two version of Python on my > Tiger system: > /usr/bin/python version 2.3.5 The above is Apple-supplied Python. Apple uses it for internal scripting stuff, you should pretend it isn't there. Ignore it, don't use it, but whatever you do, don't try to remove or replace it. > /usr/local/bin/python version 2.4.1 This is the one you want. If your shell doesn't already point to this by default when you type "python" on the command line, it should. Try "which python" to see what your default is. > Second problem: > The (Apple) installed version of sqlite3 is 3.0.8.6 > py-sqlite 2.1 requires sqlite 3.2.2 > py-sqlite 2.0 requires sqlite 3.1 > py-sqlite 1.1 requires sqlite 3.x > So it seems that py-sqlite 1.1 is the one I need. To complicate matters, there is also APSW (Another Python SQLite Wrapper) which can be used with any version of SQLite. http://www.rogerbinns.com/apsw.html > If I install it my installed py-sqlite that used the python sqlite > version 2 gets overwritten, not nice. It also seems to get > instaslled in the python 2.3 library, also not nice. Probably your PATH environment variable points to the Apple-installed python before the current python. You can change this, probably in the ".bash-profile" file in your home directory. Make sure /usr/local/bin comes before /usr/bin in the PATH. > If I go to darwin ports it wants to upgrade my python to 2.4.2 first. Why do you need DarwinPorts? You have both Python and SQLite installed already. Just download the wrapper (pysqlite or apsw) and install it using "python setup.py build; sudo python setup.py install" after making sure the correct python is in your PATH. > Does anyone have a solution? See above. > All in all the whole Python database (lack of) mess is ridiculous! I > know that Guido does not feel that databases have any place in python > but I don't get it, why does the "batteries included" not include > database support, databases like MySQL, PostgreSQL & SQLite? Python's batteries do include BerkelyDB "out of the box", as well as gdbm and/or dbm, including a built-in portable implementation of dbm for platforms that don't have it already. There are wrappers for PostgreSQL, MySQL, Oracle, SQLite, etc. There are object-relational mappings like SQLObject. The python world has a very rich and lively database environment. > At this point I am ready to mostly give up on Python after over 10 > years of use and evangelizing. That would be too bad. It's just getting really good. --Dethe ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
Re: [Pythonmac-SIG] SQLite & python
On 28 Mar 2006, at 1320, Dan Grassi wrote: > All in all the whole Python database (lack of) mess is ridiculous! I > know that Guido does not feel that databases have any place in python > but I don't get it, why does the "batteries included" not include > database support, databases like MySQL, PostgreSQL & SQLite? Funny you mention that...there's a related discussion on python-dev that just began this morning. http://mail.python.org/pipermail/python-dev/2006-March/062905.html Guido hasn't weighed in yet, though. ___ Pythonmac-SIG maillist - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
[Pythonmac-SIG] Bulding numpy with the Universal Build
Hi all, I'm embarking on the project of building the various packages I need with the new Universal Build. I've set up a Wiki page to keep track of what I (and others) have done. Please take a look if you are interested, and add your own work. http://pythonmac.org/wiki/UniversalPackages -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 - [email protected] http://mail.python.org/mailman/listinfo/pythonmac-sig
