Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Test failure in test_sysconfig_module #59389

Closed
birkenfeld opened this issue Jun 25, 2012 · 22 comments
Closed

Test failure in test_sysconfig_module #59389

birkenfeld opened this issue Jun 25, 2012 · 22 comments
Assignees
Labels
OS-mac release-blocker stdlib Python modules in the Lib dir

Comments

@birkenfeld
Copy link
Member

BPO 15184
Nosy @birkenfeld, @ronaldoussoren, @pitrou, @tarekziade, @ned-deily, @merwok, @koobs
Files
  • issue15184_osx_support.patch
  • Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.

    Show more details

    GitHub fields:

    assignee = 'https://github.com/ned-deily'
    closed_at = <Date 2012-07-22.10:24:52.893>
    created_at = <Date 2012-06-25.19:15:34.173>
    labels = ['OS-mac', 'library', 'release-blocker']
    title = 'Test failure in test_sysconfig_module'
    updated_at = <Date 2012-07-22.10:24:52.893>
    user = 'https://github.com/birkenfeld'

    bugs.python.org fields:

    activity = <Date 2012-07-22.10:24:52.893>
    actor = 'ned.deily'
    assignee = 'ned.deily'
    closed = True
    closed_date = <Date 2012-07-22.10:24:52.893>
    closer = 'ned.deily'
    components = ['Distutils', 'macOS']
    creation = <Date 2012-06-25.19:15:34.173>
    creator = 'georg.brandl'
    dependencies = []
    files = ['26164']
    hgrepos = []
    issue_num = 15184
    keywords = ['patch']
    message_count = 22.0
    messages = ['164005', '164042', '164046', '164079', '164104', '165657', '165767', '165789', '166016', '166017', '166029', '166030', '166034', '166035', '166039', '166040', '166041', '166047', '166051', '166104', '166115', '166118']
    nosy_count = 9.0
    nosy_names = ['georg.brandl', 'ronaldoussoren', 'pitrou', 'tarek', 'ned.deily', 'eric.araujo', 'python-dev', 'sbt', 'koobs']
    pr_nums = []
    priority = 'release blocker'
    resolution = 'fixed'
    stage = 'resolved'
    status = 'closed'
    superseder = None
    type = None
    url = 'https://bugs.python.org/issue15184'
    versions = ['Python 3.3']

    @birkenfeld
    Copy link
    Member Author

    On default, have this single failure on my box (Gentoo amd64):

    ======================================================================
    FAIL: test_sysconfig_module (distutils.tests.test_sysconfig.SysconfigTestCase)
    ----------------------------------------------------------------------

    Traceback (most recent call last):
      File "/home/gbr/devel/python/Lib/distutils/tests/test_sysconfig.py", line 105, in test_sysconfig_module
        self.assertEqual(global_sysconfig.get_config_var('LDSHARED'),sysconfig.get_config_var('LDSHARED'))
    AssertionError: 'gcc -pthread -shared' != '/usr/bin/clang -shared'
    - gcc -pthread -shared
    + /usr/bin/clang -shared

    While clang is installed, I haven't set anything to clang while configuring, or in my environment.

    @birkenfeld birkenfeld added the tests Tests in the Lib/test dir label Jun 25, 2012
    @ned-deily
    Copy link
    Member

    This test failure points at a few issues:

    • The CFLAGS modification should only be taking place on OS X systems. AFAICT, all of that code is protected by sys.platform checks. One possible culprit, though, might be distutils test test_unixccompiler which attempts to test various platforms by mocking sys.platform. It so happens that "darwin" is the first platform it tests and, while the test setup and teardown does preserve and restore the get_config_var function in distutils.sysconfig, it doesn't preserve the module global _config_vars which distutils.sysconfig uses to cache the results of parsing the Makefile. I wonder what happens if test_unixccompiler happens to be the first caller of distutils.sys_config_vars(). I think it will get invoked with sys.platform = 'darwin' and trigger the customization code on what becomes the cached copy for remaining tests. I'm attaching a patch to preserve and restore the cached values as well. Georg, I'd appreciate it if you could try this on your system.

    • More importantly, the test failure shows that the code we added for Xcode 4 support in bpo-13590 only addressed distutils.sysconfig and not the identical code in standalone sysconfig. With the removal of packaging in 3.3, AFAIK there now is nothing in the standard library that should depend on this at the moment but it will undoubtedly be an issue for distutil2 and future packaging features. We had discussed dealing with this by factoring out the common customization code into a separate module to avoid DRY but I didn't get that done. I'm attaching a first rough patch that does that; it is only very lightly tested and so should not be a candidate for 3.3.0b1.

    I recommend the following steps:

    1. For 3.3.0b1, either ignore the test failure or add a skip for 3.3.0b1. (This failure will also likely show up if OS X installer users attempt to run the tests.)
    2. Resolve the test failure on non-OS X platforms.
    3. Test and review the refactoring patch and plan to push it for 3.3.0rc1.
    4. Post 3.3.0, regardless of the outcome of the proposed packaging PEPs, finally replace distutils.sysconfig with sysconfig. Attempting to continue to maintain both of them is just asking for more trouble.

    @ned-deily ned-deily added stdlib Python modules in the Lib dir OS-mac deferred-blocker and removed tests Tests in the Lib/test dir labels Jun 26, 2012
    @ned-deily ned-deily self-assigned this Jun 26, 2012
    @birkenfeld
    Copy link
    Member Author

    Sounds good.

    @merwok
    Copy link
    Member

    merwok commented Jun 26, 2012

    Moving stuff common to both sysconfig modules into a shared module sounds good, but the existence and API of distutils.sysconfig needs to be preserved.

    @birkenfeld
    Copy link
    Member Author

    Moving to blocker for beta2.

    @ned-deily
    Copy link
    Member

    Georg, are you still able to reproduce this? I've subsequently tried on a Debian platform with an installed clang and could not reproduce. And, after further inspecting the current code, I really don't see how the clang substitution could happen on a non-darwin platform. My initial speculation about test_unixcompiler was incorrect as well as the proposed patch to preserve config vars in it (that test does not actually affect _config_vars and _config_vars is a dict so has to be deep-copied to be restorable). I'm proceeding with the _osx_support consolidation but I sure would like to know what was behind the behavior you reported.

    @sbt
    Copy link
    Mannequin

    sbt mannequin commented Jul 18, 2012

    I suspect the problem is related to http://bugs.python.org/issue15298.

    Basically the global sysconfig module caches the results of parsing Makefile in Lib/_sysconfigdata.py. This can cause you to get the config vars from an old configure and build.

    @ned-deily
    Copy link
    Member

    I don't see how this is related to bpo-15298. In the failure here, sysconfig returns the expected value; the problem is with what distutils.sysconfig returns.

    @python-dev
    Copy link
    Mannequin

    python-dev mannequin commented Jul 21, 2012

    New changeset d76b83803e7e by Ned Deily in branch 'default':
    Issue bpo-15184: Ensure consistent results of OS X configuration
    http://hg.python.org/cpython/rev/d76b83803e7e

    @ned-deily
    Copy link
    Member

    I've committed an updated version of the refactoring patch which attempts to handle some additional edge cases and which includes a number of additional tests. I still have not been able to reproduce the original failure so I'm setting the status to pending awaiting a test report from Georg or someone else who is able to reproduce it.

    @ned-deily
    Copy link
    Member

    @birkenfeld
    Copy link
    Member Author

    Damn, I don't have clang on this machine. Will install and test.

    @pitrou
    Copy link
    Member

    pitrou commented Jul 21, 2012

    Buildbot test failure:
    http://buildbot.python.org/all/builders/AMD64%20Snow%20Leopard%203.x/builds/66

    These failures are not new, and the buildbot is an unstable one.

    As for clang, the Lion buildbot uses it and is green. Its configure line is "./configure --with-pydebug CC=clang":
    http://buildbot.python.org/all/builders/AMD64%20Lion%203.x

    @ned-deily
    Copy link
    Member

    The problem isn't with clang. The problem was that the test appeared to be taking an OS X only code path apparently because a clang was installed on a Gentoo machine.

    @birkenfeld
    Copy link
    Member Author

    OK, test passes here now with clang installed.

    @koobs
    Copy link

    koobs commented Jul 21, 2012

    FYI, Added two FreeBSD based buildslaves to the cluster not long ago, one is dedicated to python+CLANG

    http://buildbot.python.org/all/buildslaves/koobs-freebsd-clang

    @ned-deily
    Copy link
    Member

    The new buildbot failure is due to that buildbot using env variables for some of the config variables during execution. The new tests need to isolate themselves from that. Should have a fix shortly.

    @python-dev
    Copy link
    Mannequin

    python-dev mannequin commented Jul 21, 2012

    New changeset 295b715b6875 by Ned Deily in branch 'default':
    Issue bpo-15184: Ensure configuration-related environment variables
    http://hg.python.org/cpython/rev/295b715b6875

    @ned-deily
    Copy link
    Member

    I believe I've fixed the buildbot failure but the buildbot is not very stable and test runs aren't always completing. I'll check back on it later.

    @python-dev
    Copy link
    Mannequin

    python-dev mannequin commented Jul 22, 2012

    New changeset 31349bc40214 by Ned Deily in branch 'default':
    Issue bpo-15184: Fix test__remove_unsupported_archs failures on 10.6
    http://hg.python.org/cpython/rev/31349bc40214

    @python-dev
    Copy link
    Mannequin

    python-dev mannequin commented Jul 22, 2012

    New changeset c286d50ecd19 by Ned Deily in branch 'default':
    Issue bpo-15184: Some config variables in test_sysconfig_module
    http://hg.python.org/cpython/rev/c286d50ecd19

    @ned-deily
    Copy link
    Member

    The buildbot failures were reproducible on OS X 10.6 with Xcode 3. With the latest two fixes and with the fixes for bpo-15188, I believe this issue is resolved for 3.3.

    @ezio-melotti ezio-melotti transferred this issue from another repository Apr 10, 2022
    Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
    Labels
    OS-mac release-blocker stdlib Python modules in the Lib dir
    Projects
    None yet
    Development

    No branches or pull requests

    5 participants