Created attachment 47 [details]
proposed patch

This patch addresses the issues at least on OS X with stuff installed from
MacPorts.

(In reply to comment #1)
> Created an attachment (id=47) [details]
> proposed patch
> 
> This patch addresses the issues at least on OS X with stuff installed from
> MacPorts.

I believe this isn't the best fix, as it is crucial that the bindings can be
installed on other directories, required by some build systems.

Maybe checking for the SITE_PACKAGE variable before running this code?

(In reply to comment #2)
> (In reply to comment #1)
> > Created an attachment (id=47) [details] [details]
> > proposed patch
> > 
> > This patch addresses the issues at least on OS X with stuff installed from
> > MacPorts.
> 
> I believe this isn't the best fix, as it is crucial that the bindings can be
> installed on other directories, required by some build systems.

Okay, I understand that installing e.g. to /usr/local should be possible.

I guess on Mac you can hack the installation path by saying to cmake:
 
-DCMAKE_INSTALL_PREFIX=/opt/local/Library/Frameworks/Python.framework/Versions/2.6

but that doesn't sound right either because I think then _everything_ (also
libs) would be installed there. Maybe there should be another cmake variable
where you can force the python site-packages prefix if needed?

In most cases I think you could rely on the default that distutils provides.
When prefix is given, it basically fixes the path to
$prefix/lib/python$pythonver/site-packages, ignoring all platform-recommended
locations.

> Maybe checking for the SITE_PACKAGE variable before running this code?

You mean something like -DSITE_PACKAGE=/custom/location/pythonX.X/site-packages
?

Fixed in commit:

http://qt.gitorious.org/pyside/pyside/commit/33f7ff2b4d26cede665a087178ca444c6d0894dd

If you don't want to install python on the site-packages directory found, you
just need to pass your custom site packages to cmake with
-DSITE_PACKAGE=/foo/bar

(In reply to comment #4)
> Fixed in commit:
> 
> http://qt.gitorious.org/pyside/pyside/commit/33f7ff2b4d26cede665a087178ca444c6d0894dd
> 
> If you don't want to install python on the site-packages directory found, you
> just need to pass your custom site packages to cmake with
> -DSITE_PACKAGE=/foo/bar

This seems more like a workaround than proper fix. Please note that with the
sysconfig.get_python_lib() call you are not doing any detection at all because
you are always supplying the prefix. You could as well derive the path with
$prefix/lib/python$pythonver/site-packages without calling any python code.

The case at least on MacOS is that if you _don't_ use prefix with
sysconfig.get_python_lib(), you would do real detection and you would get the
correct system path. Now with the workaround, instead of doing detection, one
must specify it manually.

(In reply to comment #5)
> This seems more like a workaround than proper fix. Please note that with the
> sysconfig.get_python_lib() call you are not doing any detection at all because
> you are always supplying the prefix. You could as well derive the path with
> $prefix/lib/python$pythonver/site-packages without calling any python code.
> 
> The case at least on MacOS is that if you _don't_ use prefix with
> sysconfig.get_python_lib(), you would do real detection and you would get the
> correct system path. Now with the workaround, instead of doing detection, one
> must specify it manually.

The problem is, if we don't use the prefix on MacOSX will be impossible to
install PySide on a sandbox on MacOSX, when we pass a prefix, even a empty one,
to sysconfig.get_python_lib(), it will return <prefix>/lib/..., but it we don't
pass the prefix argument it returns /Library/..., I dont know where is the
better place to install libraries and headers on MacOSX, so we are installig it
their UNIX usual places (/usr/lib and /usr/include), so we use the /usr prefix
when not installing on a sandbox, Are these the right places? or the right is
something like Frameworks/something?

I'll reopen the bug, assuming that you will help us to find the better way to
fix this issue on MacOSX

(In reply to comment #6)
> (In reply to comment #5)
> > This seems more like a workaround than proper fix. Please note that with the
> > sysconfig.get_python_lib() call you are not doing any detection at all because
> > you are always supplying the prefix. You could as well derive the path with
> > $prefix/lib/python$pythonver/site-packages without calling any python code.
> > 
> > The case at least on MacOS is that if you _don't_ use prefix with
> > sysconfig.get_python_lib(), you would do real detection and you would get the
> > correct system path. Now with the workaround, instead of doing detection, one
> > must specify it manually.
> 
> The problem is, if we don't use the prefix on MacOSX will be impossible to
> install PySide on a sandbox on MacOSX, when we pass a prefix, even a empty one,
> to sysconfig.get_python_lib(), it will return <prefix>/lib/..., but it we don't
> pass the prefix argument it returns /Library/..., I dont know where is the
> better place to install libraries and headers on MacOSX, so we are installig it
> their UNIX usual places (/usr/lib and /usr/include), so we use the /usr prefix
> when not installing on a sandbox, Are these the right places? 

I would say no because /usr/lib/pythonX.X/site-packages is not in the default
python path. It does not even exist on Mac OS.

What is "installing on a sandbox"?

> or the right is
> something like Frameworks/something?

For both MacOS Python (at least 2.6 in Snow Leopard), and MacPorts Python
sysconfig.get_python_lib() returns the correct location, _when called without
giving a prefix_. In the first case it is '/Library/Python/X.Y/site-packages'
and for MacPorts
'/opt/local/Library/Frameworks/Python.framework/Versions/X.Y/lib/pythonX.Y/site-packages'.

So, on Mac you should just call the function without giving any prefix. You
could still, however, allow the users to specify the site-packages dir (prefix
or full path) manually with some define.

I hope that clarifies the situation.

(In reply to comment #7)

> What is "installing on a sandbox"?

It means installing PySide (or any other package, for that matter) in a place
other than the default paths for testing purposes, so it will not disrupt any
installation you may already have. Doing things this way, all you need to use
the "sandboxed" installation is set the PYTHONPATH environment variable. Below
is a Linux example (supposing PySide is installed on /opt/sandbox/pyside):

PYTHONPATH=/opt/sandbox/pyside/lib/python2.6/site-packages:$PYTHONPATH python
-c 'import PySide.QtCore'

Just my R$ 0.02 (and sorry for barging in).

As a better option was not fount at the moment, I'll consider the current
workaround as a fix like I did before :-).

(In reply to comment #9)
> As a better option was not fount at the moment, I'll consider the current
> workaround as a fix like I did before :-).

If the correct way on OS X is to call sysconfig.get_python_lib without the
prefix argument, wouldn't the proper fix be to add a test whether we're on OS X
and call the function with or without it accordingly? Or even just test whether
the prefix is empty and omitting the argument in that case?

I'd be tempted to reopen but since I'm not 100% sure I got the issue right,
I'll let others do that. ;-)