Christopher Barker wrote:
> * What about people installing upgrades to packages? IIUC, the Apple
> python puts stuff in a dir that is before site-packages, so if you
> install a newer version of a package that Apple already had, it won't be
> used without sys.path manipulations. I think numpy was
On 3 Jan, 2008, at 19:28, Tobias Rodäbel wrote:
On Jan 3, 2008, at 5:27 PM, Ronald Oussoren wrote:
I want to do whatever keeps my live as easy as possible, either an
umbrella package with small hotfix packages or one package that
installs all hotfixes. I also want to keep the addon package
On 3 Jan, 2008, at 18:42, Bill Janssen wrote:
* Hotfix for distutils to ensure that distutils builds univeral
binaries (32-bit only at first)
Is there a bug # for this? Possibly with a patch that we could start
with :-?
There is a fix in python's repository. I'll have to look up the
deta
On Jan 3, 2008, at 5:27 PM, Ronald Oussoren wrote:
> I want to do whatever keeps my live as easy as possible, either an
> umbrella package with small hotfix packages or one package that
> installs all hotfixes. I also want to keep the addon package as
> small as possible and don't want to en
> * Hotfix for distutils to ensure that distutils builds univeral
> binaries (32-bit only at first)
Is there a bug # for this? Possibly with a patch that we could start
with :-?
Bill
___
Pythonmac-SIG maillist - Pythonmac-SIG@python.org
http://mail
On Jan 3, 2008, at 10:27 AM, Ronald Oussoren wrote:
>> I think that for "true" end users Idle is the only serious
>> omission. The first one is really for developers only, and the
>> second one doesn't really become important until such fat eggs
>> become widely available (which they are not
Ronald Oussoren wrote:
> I think we should start a small project for "MacPython Addons",
This looks very promising. Thanks for getting it going.
> this project will install:
>
> * Hotfix for distutils to ensure that distutils builds univeral
> binaries (32-bit only at first) * (possibly) hotfix
On 3 Jan, 2008, at 17:03, Jack Jansen wrote:
On 3 jan 2008, at 14:22, Ronald Oussoren wrote:
Now that there are several people that want to support Apple's
build of python: how do we go forward from here?
I think we should start a small project for "MacPython Addons",
this project will
On 3 jan 2008, at 14:22, Ronald Oussoren wrote:
> Now that there are several people that want to support Apple's build
> of python: how do we go forward from here?
>
> I think we should start a small project for "MacPython Addons", this
> project will install:
>
> * Hotfix for distutils to en
Ronald Oussoren wrote:
>
> On 3 Jan, 2008, at 15:18, Andrew Jaffe wrote:
>>
>> I'm not sure whether this is the correct thread/place for this, but is
>> there any official "best practice" for Python under Leopard?
>>
>> I.E., should we still be using the MacPython framework build (since I
>> assum
On 3 Jan, 2008, at 15:18, Andrew Jaffe wrote:
Hi All,
I'm not sure whether this is the correct thread/place for this, but is
there any official "best practice" for Python under Leopard?
This is the right thread for that (albeith one with a lame subject).
I.E., should we still be using th
Hi All,
I'm not sure whether this is the correct thread/place for this, but is
there any official "best practice" for Python under Leopard?
I.E., should we still be using the MacPython framework build (since I
assume that is more likely to track current python versions than the
Apple build). I
Now that there are several people that want to support Apple's build
of python: how do we go forward from here?
I think we should start a small project for "MacPython Addons", this
project will install:
* Hotfix for distutils to ensure that distutils builds univeral
binaries (32-bit only
> Even though I've been an open source developer since long before the
> word existed I find that I'm getting sick and tired of the reinvent-
> the-world attitude that is far too common in the open source community.
>
> If I am new to Python on the Mac and I've played with Apple Python a
> li
Ronald Oussoren wrote:
>
> On 23 Dec, 2007, at 9:01, Christopher Barker wrote:
>
>> Jack Jansen wrote:
>>> The real problem is when I couldn't care less about package X but I'm
>>> really interested in Y, which uses X, and then X forcing me to upgrade
>>> it.
>>
>> Just to make sure I understand
On 23 Dec, 2007, at 9:01, Christopher Barker wrote:
Jack Jansen wrote:
The real problem is when I couldn't care less about package X but I'm
really interested in Y, which uses X, and then X forcing me to
upgrade
it.
Just to make sure I understand -- is this an example of that:
I want to
Jack Jansen wrote:
> The real problem is when I couldn't care less about package X but I'm
> really interested in Y, which uses X, and then X forcing me to upgrade
> it.
Just to make sure I understand -- is this an example of that:
I want to use wxPython (the most recent version). I expect to
I've been thinking a bit more about being forced to upgrade package X
when I'm not interested, and I realised that the times it really
bothers me are even one more step removed: if I was interested in
package X and the website/whatever told me "don't use the current
version of X, use the ne
On Dec 21, 2007, at 12:48 AM, Jack Jansen wrote:
> I think this would be a very good idea, even if only from a
> "political" point of view.
> Even though I've been an open source developer since long before the
> word existed I find that I'm getting sick and tired of the reinvent-
> the-world atti
On Friday, December 21, 2007, at 09:48AM, "Jack Jansen" <[EMAIL PROTECTED]>
wrote:
>
>On 20 dec 2007, at 12:35, Ronald Oussoren wrote:
>
>>
>> That's easily fixable. I'm thinking about reviving Jack's MacPython
>> addons idea: a small .mpkg that will install IDLE.app, a 64-bit
>> command-line in
On 20 dec 2007, at 12:35, Ronald Oussoren wrote:
>
> That's easily fixable. I'm thinking about reviving Jack's MacPython
> addons idea: a small .mpkg that will install IDLE.app, a 64-bit
> command-line interpreter and some small fixes (such as the distutiles
> one). That should make Leopard's bu
William Kyngesburye wrote:
> On Dec 20, 2007, at 5:35 AM, Ronald Oussoren wrote:
>
>>> never provided an update within an OS-X version. (For example, if
>>> nothing else, the Apple python with Leopard doesn't build Universal
>>> Binaries when you use setup.py)
>>
>> That's easily fixable.
Yes, it
William Kyngesburye wrote:
> On Dec 20, 2007, at 5:35 AM, Ronald Oussoren wrote:
>
>>> never provided an update within an OS-X version. (For example, if
>>> nothing else, the Apple python with Leopard doesn't build Universal
>>> Binaries when you use setup.py)
>>
>> That's easily fixable.
Yes, it
On Dec 20, 2007, at 5:35 AM, Ronald Oussoren wrote:
>> never provided an update within an OS-X version. (For example, if
>> nothing else, the Apple python with Leopard doesn't build Universal
>> Binaries when you use setup.py)
>
> That's easily fixable. I'm thinking about reviving Jack's MacPython
I support your decision not to fully support Apple's python, and Mac Ports
uses internal distros of all supported software. (in other words. if pyhton
2.5 is a dependency, you will wind up with MacPorts' version of python at
/opt/local/bin/ and it's up to you to decide which one to use.
On Dec 20,
On 19 Dec, 2007, at 23:21, Christopher Barker wrote:
> Nehemiah Dacres wrote:
>> so we're still not supporting Apple's shipped python?
That depends on what you mean by "support" ;-)
>>
>
> Well, Apple does what Apples does. Every single version of python that
> they have shipped as had at least
Nehemiah Dacres wrote:
> so we're still not supporting Apple's shipped python?
Well, Apple does what Apples does. Every single version of python that
they have shipped as had at least one bug (or misfeature), and they have
never provided an update within an OS-X version. (For example, if
nothin
Nehemiah Dacres wrote:
> perhaps you should send this to macports.
Or forget macports, install the 2.5 macpython Universal framework build
and as many of the packages you need that you can find on:
http://pythonmac.org/packages/py25-fat/index.html
Then try to build/install the rest of the on
perhaps you should send this to macports. you see, Mac Ports normally
installs stuff in /opt/local/bin. but that is not where this code is being
ran from according to your traceback.
"Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/django/db/backends/postgresql_psycopg2
Using MacPorts (installed yesterday and updated today), I installed:
py25-psycopg2 @2.0.5.1_0 (active)
which pulls in the following as dependencies:
postgresql81 @8.1.10_0+darwin_8 (active)
python25 @2.5.1_4+darwin_8 (active)
then I installed:
postgresql81-server @8.1.10_0 (active)
subver
30 matches
Mail list logo
