Re: [Pythonmac-SIG] Python control/integration of a Cocoa/Quicktime application?

[Dethe Elza]

On 11/2/07, Darran Edmundson <[EMAIL PROTECTED]> wrote:
>  > The bare minimum you need is:
>  > import objc
>  > objc.loadBundle('MyBundle', globals(),
>  > bundle_path='/my/bundle/path/MyBundle.framework')

One more thing.  While the above is a bare minimum from the command
line or to work with the framework locally, you'll need a skintch more
to get the file paths to work when the framework is packaged into your
application bundle.  Below is an example I use to package Tim
Omernick's CocoaSequenceGrabber framework, and it works both from the
command line and in the app bundle.  I have this saved as
PySight/__init__.py and can then use all the framework objects and
methods by simply importing PySight in my project.

Again, if any of this is not clear, or you're not sure how to
customize this to your project, just let me know.

import objc, AppKit, Foundation, os
if 'site-packages.zip' in __file__:
  base_path = os.path.join(os.path.dirname(os.getcwd()), 'Frameworks')
else:
  base_path = '/Library/Frameworks'
bundle_path = os.path.abspath(os.path.join(base_path, 'CocoaSequenceGrabber.fram
ework'))
objc.loadBundle('CocoaSequenceGrabber', globals(), bundle_path=bundle_path)
del objc, AppKit, Foundation, os, base_path, bundle_path

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

Re: [Pythonmac-SIG] Python control/integration of a Cocoa/Quicktime application?

[Dethe Elza]

On 11/2/07, Darran Edmundson <[EMAIL PROTECTED]> wrote:
> Now that we have a proof-of-concept Objective-C framework, I'm trying to
>   port a simple test application to python.   Keep in mind that I didn't
> write either of these.  I'm a complete neophyte in terms of Mac
> development and ObjectiveC; all I have going for me is a lot of python
> experience on Windows.  Issues I'm having:
>
> - In a terminal, 'python' still gives me Apple's native 2.3 rather than
>MacPython 2.4.  Do I uninstall Apple's version or simply ensure that
>the MacPython version comes earlier in the system path?

Just make sure python2.5 comes earlier in your path.  Never uninstall
Apple's version--your computer uses it for system operations.

> - The pyObjC online docs discuss XCode templates and a distutils
>approach.  Is the latter deprecated, or still a reasonable approach?

I would use the distutils (actually, I think it is setuptools now)
approach.  The XCode templates have been fixed in Leopard (or so I
have heard), but I don't think they were very helpful in Tiger.

You can easy_install setuptools and py2app.  Below is a bare-bones
setup.py that you can customize by replacing variables with the word
"YOUR" in them.  Sorry about the over-abundance of ALL CAPS.  I have
this set up so I can re-use it quickly, so there are a bunch of
semi-constants I use in all caps, then I added more for your
customization.  Let me know if it is confusing.

'''
Minimal setup.py example, run with:
% python setup.py py2app
'''

from distutils.core import setup
import py2app

NAME = 'YOUR_APP_NAME'
SCRIPT = 'YOUR_PYTHON_SCRIPT.py'
VERSION = 'YOUR_VERSION'
ICON = ''
ID = 'A_UNIQUE_STRING
COPYRIGHT = 'Copyright 2007 YOUR_NAME'
DATA_FILES = ['English.lproj'] # This is needed if you use nib files
to define your UI

plist = dict(
CFBundleIconFile= ICON,
CFBundleName= NAME,
CFBundleShortVersionString  = ' '.join([NAME, VERSION]),
CFBundleGetInfoString   = NAME,
CFBundleExecutable  = NAME,
CFBundleIdentifier  = 'org.YOUR_DOMAIN.examples.%s' % ID,
NSHumanReadableCopyright= COPYRIGHT
)


app_data = dict(script=SCRIPT, plist=plist)
py2app_opt = dict(frameworks=['YOUR_FRAMEWORK_HERE.framework'],)
options = dict(py2app=py2app_opt,)

setup(
  data_files = DATA_FILES,
  app = [app_data],
  options = options,
)
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] Problem with numpy on Leopard

[Ronald Oussoren]

On 2 Nov, 2007, at 12:32, Kent Johnson wrote:


Christopher Barker wrote:
I suppose this may be a time to take a good look at workingenv  
again...


Or virtualenv which has replaced workingenv:
http://pypi.python.org/pypi/virtualenv


Virtualenv almost but not quite works on OSX. I've donated the code  
that deals with framework installs, but it turns out that activating  
those environments only works in some situations. Either calling the  
activate using a relative path worksor it works using an absolute  
path, but not both.


Yet another challenge :-)

Ronald



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




smime.p7s
Description: S/MIME cryptographic signature
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] Leopard python architectures in setup.py

[Ronald Oussoren]

On 2 Nov, 2007, at 21:38, Martina Oefelein wrote:



Am 02.11.2007 um 08:03 schrieb Ronald Oussoren:

As you've noticed the actual framework is 64bit but the commandline  
tools are not. It should be easy enough to add 64-bit command-line  
tools as well, but even then you'll have to add extra arguments to  
build 64-bit extensions (as Boyd mentions).


I think this actually makes sense: if the command line tools were  
32/64 bit universal, scripts would run with the 64 bit version on 64  
bit systems, and wouldn't be able to use any of the libraries that  
are only 32 bit.


The framework, on the other hand, should be 32/64 bit universal so  
that both 32 and 64 bit applications can embed python.


It's to bad that they don't ship 64-bit command-line utilities as  
well. Oh well, I guess that's an opportunity for the community: build  
a small installer that will install 64-bit commandline tools (e.g. a  
python64 command) as well as the stuff that should be in /Application/ 
MacPython 2.5.


This is not too hard, but slightly harder than it seems at first  
glance because one should also hack distutils such that python64 will  
build 64-bit (or even 4-way universal) binaries while the normal 32- 
bit binaries should keep functioning exactly as they do now.


Ronald



ciao
Martina





smime.p7s
Description: S/MIME cryptographic signature
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] Leopard python architectures in setup.py

[Ronald Oussoren]

On 2 Nov, 2007, at 22:02, Boyd Waters wrote:



On Nov 2, 2007, at 2:38 PM, Martina Oefelein wrote:


I think this actually makes sense: if the command line tools were
32/64 bit universal, scripts would run with the 64 bit version on 64
bit systems, and wouldn't be able to use any of the libraries that
are only 32 bit.

The framework, on the other hand, should be 32/64 bit universal so
that both 32 and 64 bit applications can embed python.



This gets a bit tricky with Python GUIs.  I haven't checked, but I  
suppose that PyObjC is still 32-bit only.


PyObjC is still 32-bit, but that won't be for long, I just ran out of  
time w.r.t. the Leopard deadline.


Ronald



smime.p7s
Description: S/MIME cryptographic signature
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] Python control/integration of a Cocoa/Quicktime application?

[Darran Edmundson]

Dethe Elza wrote:
> If you write an Objective-C framework, the python code to wrap it
> using PyObjC is very short.  Here is an example I use to expose Tim
> Omernick's CocoaSequenceGrabber framework to capture images from the
> iSight camera ...

 > The bare minimum you need is:
 > import objc
 > objc.loadBundle('MyBundle', globals(),
 > bundle_path='/my/bundle/path/MyBundle.framework')


Now that we have a proof-of-concept Objective-C framework, I'm trying to 
  port a simple test application to python.   Keep in mind that I didn't 
write either of these.  I'm a complete neophyte in terms of Mac 
development and ObjectiveC; all I have going for me is a lot of python 
experience on Windows.  Issues I'm having:

- In a terminal, 'python' still gives me Apple's native 2.3 rather than
   MacPython 2.4.  Do I uninstall Apple's version or simply ensure that
   the MacPython version comes earlier in the system path?

- The pyObjC online docs discuss XCode templates and a distutils
   approach.  Is the latter deprecated, or still a reasonable approach?

- Following Dethe's advice, I can successfully
  obj.loadBundle('EDMDisplayController', ...)
   from within IDLE.  I'm not at all clear on how to proceed from
   here ;-)  It seems there's some infrastructure required even for the
   simplest of applications, correct?  I.e., I can't just expect to
   create a single python script callable from the command line ...

As much as I like independent learning, I could really do with someone 
to walk me through this one-on-one.  Anyone interested in a few hours of 
consulting?  If so, just email me a rate and availability over the next 
week.  I can give you SVN access to our code, and we can chat on the 
phone or Skype.

Cheers,
Darran.


-- 
Darran Edmundson [EMAIL PROTECTED]
http://www.edmstudio.com
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] Python TkAqua, Tkinter bug

[Kevin Walzer]

Dave Reed wrote:
> 

> 
> I'm not certain exactly what you're saying. Are you saying to install 
> Active State's Python? It looks like that doesn't include a new Tk Aqua. 
> Or are you saying to install Active State's Tcl? I'm not certain how 
> installing the latter by itself will change which Tk my Python uses.
>

Installing ActiveTcl will put a framework build of TkAqua in 
/Library/Frameworks. Assuming you are using the Python from python.org, 
the ActiveState build will be picked up by Python before the one bundled 
by Apple, which is in /System/Library/Frameworks.

It's highly unlikely that bugs in 8.4.7 will be fixed at this point, if 
they haven't been fixed already.

-- 
Kevin Walzer
Code by Kevin
http://www.codebykevin.com
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] Python TkAqua, Tkinter bug

[Dave Reed]

On Nov 2, 2007, at 6:32 PM, Kevin Walzer wrote:

> [EMAIL PROTECTED] wrote:
>> I am not certain where the problem is or who to report it to, but   
>> there is a bug in TkAqua, Tkinter, or possibly OS X's windowing   
>> system. I am using a simple module on top of Tkinter for teaching  
>> an  intro programming course. When I click the mouse in the  
>> Tkinter  window, it often reports the wrong coordinates for the  
>> click most of  the time. If I use idle and first click on the Tk  
>> Console window and  then in the graphical window it seems to work.  
>> If I don't click in the  Tk Console window or start Python from the  
>> Terminal, it almost always  reports wrong values.
>> I am running Leopard now and tried both the built-in Python 2.5  
>> and  installing the version from python.org. Some of my students  
>> who are  using Tiger report the same issue - I don't recall  
>> problems last year  when using this on Tiger, but it's possible. On  
>> Windows, the  coordinates are always correct.
>> The graphics.py module built on top of Tkinter is available at:
>> http://mcsp.wartburg.edu/zelle/python/
>> A simple example that shows the problem is:
>> from graphics import *
>> win = GraphWin('test', 800, 800)
>> pt = win.getMouse()
>> print pt.getX(), pt.getY()
>> After clicking in the top left corner, it is clearly the wrong  
>> answer  (it should be near 0, 0 depending on how accurate your  
>> click is).
>> Any ideas on where the problem is, who to notify, etc.?
>> Thanks,
>> Dave
>
> Are you using the built-in Tk that comes with OS X? It's ancient  
> (8.4.7 on Tiger, and not updated for Leopard). Try installing a more  
> recent version, such as 8.4.16, from ActiveState and see if that  
> solves the problem.


I'm not certain exactly what you're saying. Are you saying to install  
Active State's Python? It looks like that doesn't include a new Tk  
Aqua. Or are you saying to install Active State's Tcl? I'm not certain  
how installing the latter by itself will change which Tk my Python uses.

I think I figured out a work around. Instead of first clicking on the  
Tk window's title bar to move it, first click inside the Tk window to  
make it active, then use the title bar to move it, and then clicks  
seem to respond with the correct coordinate.

Thanks,
Dave

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

Re: [Pythonmac-SIG] Python TkAqua, Tkinter bug

[Kevin Walzer]

[EMAIL PROTECTED] wrote:
> I am not certain where the problem is or who to report it to, but  
> there is a bug in TkAqua, Tkinter, or possibly OS X's windowing  
> system. I am using a simple module on top of Tkinter for teaching an  
> intro programming course. When I click the mouse in the Tkinter  
> window, it often reports the wrong coordinates for the click most of  
> the time. If I use idle and first click on the Tk Console window and  
> then in the graphical window it seems to work. If I don't click in the  
> Tk Console window or start Python from the Terminal, it almost always  
> reports wrong values.
> 
> I am running Leopard now and tried both the built-in Python 2.5 and  
> installing the version from python.org. Some of my students who are  
> using Tiger report the same issue - I don't recall problems last year  
> when using this on Tiger, but it's possible. On Windows, the  
> coordinates are always correct.
> 
> The graphics.py module built on top of Tkinter is available at:
> 
> http://mcsp.wartburg.edu/zelle/python/
> 
> A simple example that shows the problem is:
> 
> from graphics import *
> win = GraphWin('test', 800, 800)
> pt = win.getMouse()
> print pt.getX(), pt.getY()
> 
> After clicking in the top left corner, it is clearly the wrong answer  
> (it should be near 0, 0 depending on how accurate your click is).
> 
> Any ideas on where the problem is, who to notify, etc.?
> 
> Thanks,
> Dave

Are you using the built-in Tk that comes with OS X? It's ancient (8.4.7 
on Tiger, and not updated for Leopard). Try installing a more recent 
version, such as 8.4.16, from ActiveState and see if that solves the 
problem.

-- 
Kevin Walzer
Code by Kevin
http://www.codebykevin.com
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

[Pythonmac-SIG] Python TkAqua, Tkinter bug

[davelist]

I am not certain where the problem is or who to report it to, but  
there is a bug in TkAqua, Tkinter, or possibly OS X's windowing  
system. I am using a simple module on top of Tkinter for teaching an  
intro programming course. When I click the mouse in the Tkinter  
window, it often reports the wrong coordinates for the click most of  
the time. If I use idle and first click on the Tk Console window and  
then in the graphical window it seems to work. If I don't click in the  
Tk Console window or start Python from the Terminal, it almost always  
reports wrong values.

I am running Leopard now and tried both the built-in Python 2.5 and  
installing the version from python.org. Some of my students who are  
using Tiger report the same issue - I don't recall problems last year  
when using this on Tiger, but it's possible. On Windows, the  
coordinates are always correct.

The graphics.py module built on top of Tkinter is available at:

http://mcsp.wartburg.edu/zelle/python/

A simple example that shows the problem is:

from graphics import *
win = GraphWin('test', 800, 800)
pt = win.getMouse()
print pt.getX(), pt.getY()

After clicking in the top left corner, it is clearly the wrong answer  
(it should be near 0, 0 depending on how accurate your click is).

Any ideas on where the problem is, who to notify, etc.?

Thanks,
Dave


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

Re: [Pythonmac-SIG] more tab completion issues.

[Boyd Waters]

I've reported this in Apple Bug 5563035.

On Nov 1, 2007, at 9:25 PM, Michael VanLandingham wrote:

> Yeah after looking at it again, I noticed certain things, like  
> __class__, had 4, and not 1, entries in the listing.  It's a bit  
> annoying, since with something like numpy's 'array', it'll fill up  
> your window with 320+ items.
>
> I thought about debugging it, but I don't know how to intercept the  
> 'tab' keystroke in the tab completion.
>
> -mvl
>
> On Nov 1, 2007, at 7:59 PM, Boyd Waters wrote:
>
>> I get even more duplicates than that...
>> >>> i.__
>> Display all 121 possibilities? (y or n)
>> i.__abs__   i.__abs__   i.__add__
>> i.__add__   i.__and__   i.__and__
>> i.__class__ i.__class__ i.__class__  
>> i.__class__ i.__cmp__   i.__cmp__
>> i.__coerce__i.__coerce__i.__delattr__
>> i.__delattr__   i.__delattr__   i.__div__
>> ...
>>
>> Funny.
>>
>>
>>
>> On Nov 1, 2007, at 7:44 PM, Michael VanLandingham wrote:
>>
>>> Following along the whole rlcompleter/readline/editline thread, I  
>>> noticed today that when I do tab completion on a class, I get  
>>> everything listed twice.
>>> Happens in python and ipython.
>>> Example:
>>> >>> i = int(5)
>>> >>> i
>>> 5
>>> >>> i.__
>>> Display all 121 possibilities? (y or n)
>>> i.__abs__   i.__abs__   i.__add__
>>> i.__add__
>>> i.__and__   i.__and__   i.__class__  
>>> i.__class__
>>> ...etc.
>>>
>>>
>>> I don't see duplicates if I do 'dir(i)'
>>>
>>> Is anyone else seeing this behavior?  Any ideas why?  Something  
>>> in the rlcompleter or readline...  Seems to occur with any class.
>>>
>>>
>>> -Michael
>>>
>>> ___
>>> 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] sys.path on Leopard

[Brian Granger]

I think this is currently the best approach because PYTHONPATH gets
lost in sudo commands in Leopard.

On 11/1/07, Jack Jansen <[EMAIL PROTECTED]> wrote:
>
> On 1-Nov-2007, at 20:45 , Brian Granger wrote:
> > Running python setup.py install on Leopard causes packages to be
> > installed in the usual:
> >
> > /Library/Python/2.5/site-packages
> >
> > But, Apple put this directory _after_
> >
> > /System/Library/Frameworks/Python.framework/Versions/2.5/Extras/lib/
> > python
> >
> > in sys.path.  This, even if a user installs a newer version of one of
> > these packages, the builtin  python will always use Apple's older
> > version.
>
>
> Bah. The order is very strange:
> - First most of the Python-supplied and Apple-supplied directories,
> - Then /Library/Python/2.5/site-packages
> - Then PyObjC, which is also Apple-supplied
> - Then $HOME/Library/Python/2.5/site-packages, if it exists.
>
> By all means, report a bug.
>
> There is a workaround that packages can use to fix this, by the way,
> through using Python code inside a .pth file. I used that in the
> distant past to allow packman to fix bugs in system packages.
>
> I put the following line (without indentation) into ~/Library/Python/
> 2.5/site-packages/HackPath.pth
> import sys ; sys.path.insert(0, '/Users/jack/MyPythonPrependedPath')
> And, indeed, '/Users/jack/MyPythonPrependedPath' ends up as the first
> entry in sys.path.
> --
> 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] Round 2 with Leopard+Python

[Brian Granger]

Yep, here is the beginning of my /etc/sudoers:

# sudoers file.
#
# This file MUST be edited with the 'visudo' command as root.
#
# See the sudoers man page for the details on how to write a sudoers file.
#

# Host alias specification

# User alias specification

# Cmnd alias specification

# Defaults specification
Defaultsenv_reset
Defaultsenv_keep += "BLOCKSIZE"
Defaultsenv_keep += "COLORFGBG COLORTERM"
Defaultsenv_keep += "__CF_USER_TEXT_ENCODING"
Defaultsenv_keep += "CHARSET LANG LANGUAGE LC_ALL LC_COLLATE
LC_CTYPE"
Defaultsenv_keep += "LC_MESSAGES LC_MONETARY LC_NUMERIC LC_TIME"
Defaultsenv_keep += "LINES COLUMNS"
Defaultsenv_keep += "LSCOLORS"
Defaultsenv_keep += "SSH_AUTH_SOCK"
Defaultsenv_keep += "TZ"
Defaultsenv_keep += "DISPLAY XAUTHORIZATION XAUTHORITY"
Defaultsenv_keep += "EDITOR VISUAL"


OK, this looks like true security feature then.  Back to playing with
.pth files then.

On 11/2/07, Boyd Waters <[EMAIL PROTECTED]> wrote:
> FYI:
>
> On Leopard, "sudo" filters environment variables, including PYTHONPATH.
>
>
> I have not tested this with MacPorts yet; I've been running MacPorts
> as a "normal" user without sudo. Will this matter for MacPorts?
>
>
> > Running "sudo -V" as root shows sudo's settings; part of that is
> > environment variables that it will not pass on or that it will
> > check for dangerous content.
>
>
> On Nov 2, 2007, at 2:59 PM, Boyd Waters wrote:
>
> > One work-around is to add this line to /etc/sudoers:
> >
> > Defaultsenv_keep += "PYTHONPATH"
> >
> >
> >
> > But that would involve editing a file in /etc as root.
> > Straightforward enough, but likely to get overwritten and what if
> > the user screws this up?
> >
> >
> > So Plan B -
> >
> > what if you added something in a .pth file in /Library/Python/2.5/
> > site-packages that re-orders the sys.path?
> >
> > Wouldn't that always work?
> >
> >
> >
> >
> > On Nov 2, 2007, at 2:49 PM, Boyd Waters wrote:
> >
> >>
> >> On Nov 2, 2007, at 10:16 AM, Brian Granger wrote:
> >>
> >>>  First, if you have set PYTHONPATH to point
> >>> sys.path at the site-packages in /Library, this setting will be lost
> >>> when you do:
> >>>
> >>> sudo python setup.py install
> >>
> >>
> >> Ouch, another good one...
> >>
> >> This is almost certainly not a bug, but rather a security feature.
> >>
> >>> The administrator can add a line to the sudoers file:
> >>>
> >>> Defaults  env_reset
> >>>
> >>> that will reset the environment to only contain the variables
> >>> HOME, LOGNAME,
> >>> PATH, SHELL, TERM, and USER, preventing this attack.
> >>
> >>
> >>
> >
>
>
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] Round 2 with Leopard+Python

[Boyd Waters]

FYI:

On Leopard, "sudo" filters environment variables, including PYTHONPATH.


I have not tested this with MacPorts yet; I've been running MacPorts  
as a "normal" user without sudo. Will this matter for MacPorts?


> Running "sudo -V" as root shows sudo's settings; part of that is  
> environment variables that it will not pass on or that it will  
> check for dangerous content.


On Nov 2, 2007, at 2:59 PM, Boyd Waters wrote:

> One work-around is to add this line to /etc/sudoers:
>
> Defaultsenv_keep += "PYTHONPATH"
>
>
>
> But that would involve editing a file in /etc as root.  
> Straightforward enough, but likely to get overwritten and what if  
> the user screws this up?
>
>
> So Plan B -
>
> what if you added something in a .pth file in /Library/Python/2.5/ 
> site-packages that re-orders the sys.path?
>
> Wouldn't that always work?
>
>
>
>
> On Nov 2, 2007, at 2:49 PM, Boyd Waters wrote:
>
>>
>> On Nov 2, 2007, at 10:16 AM, Brian Granger wrote:
>>
>>>  First, if you have set PYTHONPATH to point
>>> sys.path at the site-packages in /Library, this setting will be lost
>>> when you do:
>>>
>>> sudo python setup.py install
>>
>>
>> Ouch, another good one...
>>
>> This is almost certainly not a bug, but rather a security feature.
>>
>>> The administrator can add a line to the sudoers file:
>>>
>>> Defaults  env_reset
>>>
>>> that will reset the environment to only contain the variables  
>>> HOME, LOGNAME,
>>> PATH, SHELL, TERM, and USER, preventing this attack.
>>
>>
>>
>

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

Re: [Pythonmac-SIG] Leopard python architectures in setup.py

[Boyd Waters]

On Nov 2, 2007, at 2:38 PM, Martina Oefelein wrote:

> I think this actually makes sense: if the command line tools were
> 32/64 bit universal, scripts would run with the 64 bit version on 64
> bit systems, and wouldn't be able to use any of the libraries that
> are only 32 bit.
>
> The framework, on the other hand, should be 32/64 bit universal so
> that both 32 and 64 bit applications can embed python.


This gets a bit tricky with Python GUIs.  I haven't checked, but I  
suppose that PyObjC is still 32-bit only.

I know that Tk and Qt are 32-bit only at the moment.

That is, the Tk that ships from Apple with Leopard is 32-bit.  Qt has  
to be 32-bit for the next year or two since Apple dropped 64-bit  
Carbon (they need to port the Mac GUI to Cocoa, and that will Take  
Some Work).


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

Re: [Pythonmac-SIG] Leopard python architectures in setup.py

[William Kyngesburye]

On Nov 2, 2007, at 3:38 PM, Martina Oefelein wrote:

>
> Am 02.11.2007 um 08:03 schrieb Ronald Oussoren:
>
>> As you've noticed the actual framework is 64bit but the commandline
>> tools are not. It should be easy enough to add 64-bit command-line
>> tools as well, but even then you'll have to add extra arguments to
>> build 64-bit extensions (as Boyd mentions).
>
> I think this actually makes sense: if the command line tools were
> 32/64 bit universal, scripts would run with the 64 bit version on 64
> bit systems, and wouldn't be able to use any of the libraries that
> are only 32 bit.
>
> The framework, on the other hand, should be 32/64 bit universal so
> that both 32 and 64 bit applications can embed python.
>

That's where I'm missing info on the other ways Python can be used.   
So another package links 64bit to the python framework, but it still  
has to run from some python interpreter executable that is embedded -  
where does that interpreter come from, if not the one in the framework  
bundle?

-
William Kyngesburye 
http://www.kyngchaos.com/

"This is a question about the past, is it? ... How can I tell that the  
past isn't a fiction designed to account for the discrepancy between  
my immediate physical sensations and my state of mind?"

- The Ruler of the Universe


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

Re: [Pythonmac-SIG] Round 2 with Leopard+Python

[Boyd Waters]

On Nov 2, 2007, at 10:16 AM, Brian Granger wrote:

>  First, if you have set PYTHONPATH to point
> sys.path at the site-packages in /Library, this setting will be lost
> when you do:
>
> sudo python setup.py install


Ouch, another good one...

This is almost certainly not a bug, but rather a security feature.

> The administrator can add a line to the sudoers file:
>
> Defaults  env_reset
>
> that will reset the environment to only contain the variables HOME,  
> LOGNAME,
> PATH, SHELL, TERM, and USER, preventing this attack.



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

Re: [Pythonmac-SIG] Leopard python architectures in setup.py

[Martina Oefelein]

Am 02.11.2007 um 08:03 schrieb Ronald Oussoren:

> As you've noticed the actual framework is 64bit but the commandline  
> tools are not. It should be easy enough to add 64-bit command-line  
> tools as well, but even then you'll have to add extra arguments to  
> build 64-bit extensions (as Boyd mentions).

I think this actually makes sense: if the command line tools were  
32/64 bit universal, scripts would run with the 64 bit version on 64  
bit systems, and wouldn't be able to use any of the libraries that  
are only 32 bit.

The framework, on the other hand, should be 32/64 bit universal so  
that both 32 and 64 bit applications can embed python.

ciao
Martina

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

Re: [Pythonmac-SIG] sys.path on Leopard

[Martina Oefelein]

Am 01.11.2007 um 21:14 schrieb Jack Jansen:

>
> On 1-Nov-2007, at 20:45 , Brian Granger wrote:
>> Running python setup.py install on Leopard causes packages to be
>> installed in the usual:
>>
>> /Library/Python/2.5/site-packages
>>
>> But, Apple put this directory _after_
>>
>> /System/Library/Frameworks/Python.framework/Versions/2.5/Extras/lib/
>> python
>>
>> in sys.path.  This, even if a user installs a newer version of one of
>> these packages, the builtin  python will always use Apple's older
>> version.
>
>
> Bah. The order is very strange:
> - First most of the Python-supplied and Apple-supplied directories,
> - Then /Library/Python/2.5/site-packages
> - Then PyObjC, which is also Apple-supplied
> - Then $HOME/Library/Python/2.5/site-packages, if it exists.
>
> By all means, report a bug.
>

I think that site-packages comes after the system library is just  
normal python behaviour IMHO. At least, it's the same in the  
"official" Python 2.5.1 build from python.org, and it's also in the  
example path here:
http://docs.python.org/inst/search- 
path.html#SECTION00041


ciao
Martina

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

Re: [Pythonmac-SIG] sys.path on Leopard

[Brian Granger]

I guess then that the main different is that the 2.5.1 off python.org
doesn't include older versions of things like numpy, twisted, etc.
that people would want to upgrdate.

Brian

On 11/2/07, Martina Oefelein <[EMAIL PROTECTED]> wrote:
>
> Am 01.11.2007 um 21:14 schrieb Jack Jansen:
>
> >
> > On 1-Nov-2007, at 20:45 , Brian Granger wrote:
> >> Running python setup.py install on Leopard causes packages to be
> >> installed in the usual:
> >>
> >> /Library/Python/2.5/site-packages
> >>
> >> But, Apple put this directory _after_
> >>
> >> /System/Library/Frameworks/Python.framework/Versions/2.5/Extras/lib/
> >> python
> >>
> >> in sys.path.  This, even if a user installs a newer version of one of
> >> these packages, the builtin  python will always use Apple's older
> >> version.
> >
> >
> > Bah. The order is very strange:
> > - First most of the Python-supplied and Apple-supplied directories,
> > - Then /Library/Python/2.5/site-packages
> > - Then PyObjC, which is also Apple-supplied
> > - Then $HOME/Library/Python/2.5/site-packages, if it exists.
> >
> > By all means, report a bug.
> >
>
> I think that site-packages comes after the system library is just
> normal python behaviour IMHO. At least, it's the same in the
> "official" Python 2.5.1 build from python.org, and it's also in the
> example path here:
> http://docs.python.org/inst/search-
> path.html#SECTION00041
>
>
> ciao
> Martina
>
>
___
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig

Re: [Pythonmac-SIG] Problem with numpy on Leopard

[Nicholas Riley]

On Fri, Nov 02, 2007 at 01:06:08PM -0700, Christopher Barker wrote:
> Ned Deily wrote:
> > The easiest way is to use the install_requires keyword in setup.py.  See 
> > the setuptools documentation here:
> > 
> >  
> 
> That appears to handle dependencies:
> 
> install_requires
> A string or list of strings specifying what other distributions need to 
> be installed when this one is. See the section below on Declaring 
> Dependencies for details and examples of the format of this argument.
> 
> Which looks quite dangerous, as a matter of fact. For example, I do
> 
> easy_install foo
> 
> foo has install_requires("numpy==1.0.3")
> 
> now setuptools will download and install numpy1.0.3, but it won't get 
> used, 'cause there is an older numpy earlier on the pythonpath.

From
:

> Any scripts in your project will be installed with wrappers that
> verify the availability of the specified dependencies at runtime, and
> ensure that the correct versions are added to sys.path (e.g. if
> multiple versions have been installed).

setuptools definitely supports multiple versions of packages being
installed at once, and the ability to select them.  It rewrites your
scripts for you at installation time to resolve the depdendencies.  If
you want to use the versioned dependencies during development, that's
what 'setup.py develop' is for.

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

Re: [Pythonmac-SIG] Problem with numpy on Leopard

[Robert Kern]

Christopher Barker wrote:
> Ned Deily wrote:
>> The easiest way is to use the install_requires keyword in setup.py.  See 
>> the setuptools documentation here:
>>
>>  
> 
> That appears to handle dependencies:
> 
> install_requires
> A string or list of strings specifying what other distributions need to 
> be installed when this one is. See the section below on Declaring 
> Dependencies for details and examples of the format of this argument.
> 
> Which looks quite dangerous, as a matter of fact. For example, I do
> 
> easy_install foo
> 
> foo has install_requires("numpy==1.0.3")
> 
> now setuptools will download and install numpy1.0.3, but it won't get 
> used, 'cause there is an older numpy earlier on the pythonpath.

This is incorrect. sys.path gets modified appropriately.

-- 
Robert Kern

"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

Re: [Pythonmac-SIG] Problem with numpy on Leopard

[Christopher Barker]

Ned Deily wrote:
> The easiest way is to use the install_requires keyword in setup.py.  See 
> the setuptools documentation here:
> 
>  

That appears to handle dependencies:

install_requires
A string or list of strings specifying what other distributions need to 
be installed when this one is. See the section below on Declaring 
Dependencies for details and examples of the format of this argument.

Which looks quite dangerous, as a matter of fact. For example, I do

easy_install foo

foo has install_requires("numpy==1.0.3")

now setuptools will download and install numpy1.0.3, but it won't get 
used, 'cause there is an older numpy earlier on the pythonpath.


Anyway, I won't looking for dependency management, I was looking for 
runtime version management: i.e have numpy1.0.2 and numpy1.0.3 both 
installed, and specify in a given script which one I want to use. If 
there's a way to do that, then when you develop and test, you specify 
which numpy to use, if you, or another user has multiple versions 
installed, the correct one is use. wxPython handles this with a custom 
system:

import wxversion
wxversion.select('2.4')

or, if you've tested against more than one version:

wxversion.select(['2.5.4', '2.5.5', '2.6'])

I think PyGtk has a similar system

If this was a universal python package feature, and people used it, a 
lot of these problems would go away.

oh well, I got little support for this a few years ago, I doubt it will 
change now. I think virtualenv may be the answer -- and maybe it's a 
better one anyway -- I'll have to give it a shot.

-Chris



-- 
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R(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] Round 2 with Leopard+Python

[Christopher Barker]

Brian Granger wrote:

> But, in Leopard, sudo does not preserve environment variables:

> The solution currently is to install all packages to locations that
> don't require sudo to write to.

Or use "sudo -s", which starts a shell, then set your env vars:

$ sudo -s
$ export FOO=/tmp
$ python -c "import os; print os.environ['FOO']"

should work.

But I agree, a change like this in sudo behavior is going to cause a lot 
of problems!

-CHB



-- 
Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR&R(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] [Numpy-discussion] Problem with numpy on Leopard

[Boyd Waters]

On Nov 2, 2007, at 9:33 AM, Brian Granger wrote:

>  Now under Leopard, this becomes "python setup.py install" +
> muck with PYTHONPATH or .pth files.


I'm not sure it's that bad.

We ship a fairly complex science application. You might call it a  
very large set of Python extensions, but the C++ code is way bigger  
than the Python. Parts of our build system are 15 years old, and  
we're not set up to build everything from a top-level "setup.py". So  
I've not yet learned how to make py2app work for me.

Instead, I ship a Mac application bundle. On Tiger, it's an  
Applescript thing, that launches a bash shell script, that sets up  
the Python path to point to the app bundle first, and then launches  
the Python that's included in the app bundle. Since I don't know  
enough Python system engineering, I ship the entire Python distro  
inside the application.

That's for Tiger. It's rock-solid for the end user, no matter what  
they have installed elsewhere.

On Leopard, I'll still put all of my Python extensions inside my  
Application bundle, and I'll still use a launcher (perhaps written in  
PyObjC, since I know it will be there) that sets up the path.

The user will just double-click the application icon.

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

Re: [Pythonmac-SIG] [Numpy-discussion] Problem with numpy on Leopard

[Bill Janssen]

> I think the "FUD" you refer 
> to concerns a different problem: developing and distributing 
> multiple-component Python apps to multiple users on multiple machines.  

Well, that's actually what I do, on Tiger.  I'll be interested to see
how hard it is to do it with the system Python on Leopard.

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

[Pythonmac-SIG] Round 2 with Leopard+Python

[Brian Granger]

Hi,

In the process of working through the issues with sys.path on Leopard,
I have found another potential Leopard bug that is particularly nasty.

In Tiger, sudo preserves environment variables:

$ export FOO=/tmp
$ python -c "import os; print os.environ['FOO']"
/tmp
$ sudo python -c "import os; print os.environ['FOO']"
/tmp

But, in Leopard, sudo does not perserve environment variables:

$ export FOO=/tmp
$ python -c "import os; print os.environ['FOO']"
/tmp
$ sudo python -c "import os; print os.environ['FOO']"
Password:
Traceback (most recent call last):
  File "", line 1, in 
  File 
"/System/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/UserDict.py",
line 22, in __getitem__
raise KeyError(key)
KeyError: 'FOO'

This is a big problem.  First, if you have set PYTHONPATH to point
sys.path at the site-packages in /Library, this setting will be lost
when you do:

sudo python setup.py install

On another package.  I encountered this in building pytables, which
requires numpy >= 1.0.3.  I had installed numpy 1.0.4, and set my
PYTHONPATH to point to it.  But, the pytables setup.py script failts
because PYTHONPATH is lost and it only sees the older (1.0.1) builtin
numpy.

Second, some setup.py scripts use environment variables to determine
how things are built, find other dependencies, etc.  Currently, this
will fail on Leopard if such packages are installed into locations
that require sudo.  I haven't tried it yet, but I expect that this
will also hold true for other python installations.  The behavior also
shows up with ruby on Leopard.

The solution currently is to install all packages to locations that
don't require sudo to write to.  I will file a bug report, but until
the bug is fixed, we should explore putting a note on the numpy/scipy
site - and even possibly on the python.org site to describe the
problem and its workaround.

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

Re: [Pythonmac-SIG] Problem with numpy on Leopard

[Brian Granger]

This is definitely worth looking at for this type of thing.  Thanks
for the pointer.

Brian

On 11/2/07, Kent Johnson <[EMAIL PROTECTED]> wrote:
> Christopher Barker wrote:
> > I suppose this may be a time to take a good look at workingenv again...
>
> Or virtualenv which has replaced workingenv:
> http://pypi.python.org/pypi/virtualenv
>
> Kent
> ___
> 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] [Numpy-discussion] Problem with numpy on Leopard

[Brian Granger]

On 11/1/07, Bill Janssen <[EMAIL PROTECTED]> wrote:
> > > It's not entirely silly.  This has been the advice given to app
> > > developers on this list and the PyObjC list for years now.  It's nice
> > > to have a better system Python for quick scripts, but it's still the
> > > System Python.  It's Apples, for their stuff that uses Python.  And it
> > > is specific to OS 10.5.  If you use it to build your app, your app is
> > > pretty much guaranteed not to work when someone tries to run it on
> > > 10.6, etc.
> >
> > At some level I agree - I haven't used the system python on Tiger for
> > a long time now.  But, that is not how Apple "sells" the python on
> > their system.
>
> This is really interesting.  For my apps, I use the system Python on
> Tiger, and expect to do it again with Leopard.  If I have to have a
> specific version of an extension that's needed, I make sure the
> directory where I keep it is on the sys.path of my application before
> the standard directories.  That seems to be about all that's required.
> I'm not sure what all the FUD about the system Python is...

There is little fear, uncertainty or doubt about this.  The problem is
that this represents a huge change of behavior for users making the
transition to Leopard.  On Tiger, a user could download any basically
any python pacakge and do "python setup.py install" and things would
work.  Now under Leopard, this becomes "python setup.py install" +
muck with PYTHONPATH or .pth files.  I personally have no problem
doing this, but many of the casual python users with whom I work will
be tripped up by thisand they will come and ask me what to
doover and over again

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

Re: [Pythonmac-SIG] Problem with numpy on Leopard

[Kent Johnson]

Christopher Barker wrote:
> I suppose this may be a time to take a good look at workingenv again...

Or virtualenv which has replaced workingenv:
http://pypi.python.org/pypi/virtualenv

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