With the latest from branches/py3k, in a framework build, I get:

Wimp:build pythonbuildbot$ ./python.exe -m test.regrtest test_site
[1/1] test_site
test test_site failed -- Traceback (most recent call last):
  File "/Users/pythonbuildbot/32test/build/Lib/test/test_site.py", line 225, in test_getsitepackages
    self.assertEqual(len(dirs), 2)
AssertionError: 3 != 2

1 test failed:
    test_site
Wimp:build pythonbuildbot$ ./python.exe
Python 3.2b2+ (py3k:87899M, Jan 10 2011, 11:08:48) 
[GCC 4.0.1 (Apple Inc. build 5493)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import site
>>> site.getsitepackages()
['/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/site-packages', '/Library/Frameworks/Python.framework/Versions/3.2/lib/site-python', '/Library/Python/3.2/site-packages']

Those three dirs look correct for me, but the test is written to find exactly two from site.getsitepackages() -- the code, however, adds an extra in the event of framework builds.

... oops! Apparently dupe. Forgot to search first. Ignore.

I'd like to reopen this, as it doesn't seem to be a duplicate of #8084. Specifically, test_getsitepackages in test_sitepackages appears to be wrong, since it has a correct test for platform builds later in the method, but the failure occurs earlier because the path "os.sep == '/'" is taken on OS X. The test should be restructured as e.g.

    if sys.platform in ('os2emx', 'riscos'):
        # stuff for OS/2, RISCOS
    elif (sys.platform == "darwin" and
            sysconfig.get_config_var("PYTHONFRAMEWORK")):
        # OS X platform builds
    elif os.sep == '/':
        # OS X non-platform builds, Linux, FreeBSD etc.
    else:
        # other platforms

That the test itself is broken is not the thrust of #8084.

How can we detect framework builds from Python code?  Maybe there is a variable in sysconfig?

Hem, I should have re-read Vinay’s message before posting :)  Marking as easy.

This is now fixed in pythonv, see

https://bitbucket.org/vinay.sajip/pythonv/changeset/a59a3868d185/raw/pythonv-a59a3868d185.diff

I would like to help by reviewing the patch, however I'm unsure about how to do the framework aspect of this. Can someone send me instructions or a link on how I would set this up to test?

Thanks in advance,

IIRC what I did was clone the repo, configure and build, then

sudo make frameworkinstall

For me (on Leopard), this installed Python 3.3 in /Library/Frameworks/Python.framework, leaving my system Python (2.5.1) alone. Then you can just invoke the regression tests using

python3.3 Lib/test/regrtest.py test_site

from the appropriate directory. But note that this is a case where the test needs fixing, not the code being tested.

>   sudo make frameworkinstall

While that shouldn't affect the Apple-supplied system Pythons, be aware that with default ./configure settings this will overwrite any third-party Python installs (like from the python.org installers) of the version in question in /Library/Frameworks.  For unreleased versions, like from default that shouldn't be a big issue.  But it is safer and easy to pick some other location to install the framework.  I also usually use a different framework name to reduce the chances of accidentally dynamically linking to the wrong framework.  On a current 10.6 or 10.7 system, I'd recommend something like this:

./configure --enable-universalsdk=/Developer/SDKs/MacOSX10.6.sdk --with-universal-archs=intel '--prefix=/path/to/test/root' '--enable-framework=/path/to/test/Library' --with-framework-name=pytest_10_6 MACOSX_DEPLOYMENT_TARGET=10.6 CC=/usr/bin/gcc-4.2

On 10.4 or 10.5 systems, to simulate the 32-bit-only installer build:

./configure --enable-universalsdk=/Developer/SDKs/MacOSX10.4u.sdk --with-universal-archs=32-bit '--prefix=/path/to/test/root' '--enable-framework=/path/to/test/Library' --with-framework-name=pytest_10_3 --with-pydebug MACOSX_DEPLOYMENT_TARGET=10.3 CC=/usr/bin/gcc-4.0

Bryce, are you interested in writing a patch for the test?

I forgot to mention that one advantage of using another framework and root location, say, under your home directory somewhere, is that it is unnecessary to use sudo.  And you don't need to use the special target in any case, simply "make install".

On 11 Oct, 2011, at 22:28, Ned Deily wrote:

> 
> Ned Deily <nad@acm.org> added the comment:
> 
> I forgot to mention that one advantage of using another framework and root location, say, under your home directory somewhere, is that it is unnecessary to use sudo.  And you don't need to use the special target in any case, simply "make install".

Make install always works, the frameworkinstall target is a leftover from a time when you couldn't use "make install".

New changeset 82c4f094f811 by Ned Deily in branch '2.7':
Issue #10881: Fix test_site failures with OS X framework builds.
http://hg.python.org/cpython/rev/82c4f094f811

New changeset 013cba2eb008 by Ned Deily in branch '3.2':
Issue #10881: Fix test_site failure with OS X framework builds.
http://hg.python.org/cpython/rev/013cba2eb008

New changeset c88606bd5287 by Ned Deily in branch 'default':
Issue #10881: merge
http://hg.python.org/cpython/rev/c88606bd5287

Thanks, Vinay, for your analysis.  I adapted it for the applied fix.  For 2.7, there were two additional test_site failures that are fixed by back porting minor fixes to site.py and sysconfig.py from 3.x.  Applied in 2.7 (for 2.7.3), 3.2 (for 3.2.3), and default (for 3.3).

P.S. I forgot to mention that one of the 2.7 test_site failures was due to the PYTHONUSERBASE env variable having no effect with OS X framework builds.  That had been fixed in 3.x; it's now back ported.