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

distutils.cmd breaks inspect #46069

Closed
AstraLuma mannequin opened this issue Jan 3, 2008 · 12 comments
Closed

distutils.cmd breaks inspect #46069

AstraLuma mannequin opened this issue Jan 3, 2008 · 12 comments

Comments

@AstraLuma
Copy link
Mannequin

AstraLuma mannequin commented Jan 3, 2008

BPO 1728
Nosy @gvanrossum, @tiran, @AstraLuma
Superseder
  • bpo-1665: re.match.func_code.co_filename returns "re.py"
  • Files
  • regen: The original python script which I found the bug with.
  • 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 = None
    closed_at = <Date 2008-01-04.01:11:43.933>
    created_at = <Date 2008-01-03.19:26:29.964>
    labels = []
    title = 'distutils.cmd breaks inspect'
    updated_at = <Date 2008-01-04.01:11:43.932>
    user = 'https://github.com/AstraLuma'

    bugs.python.org fields:

    activity = <Date 2008-01-04.01:11:43.932>
    actor = 'gvanrossum'
    assignee = 'none'
    closed = True
    closed_date = <Date 2008-01-04.01:11:43.933>
    closer = 'gvanrossum'
    components = ['None']
    creation = <Date 2008-01-03.19:26:29.964>
    creator = 'AstraLuma'
    dependencies = []
    files = ['9053']
    hgrepos = []
    issue_num = 1728
    keywords = []
    message_count = 12.0
    messages = ['59145', '59147', '59150', '59151', '59157', '59159', '59161', '59162', '59167', '59170', '59171', '59195']
    nosy_count = 4.0
    nosy_names = ['gvanrossum', 'draghuram', 'christian.heimes', 'AstraLuma']
    pr_nums = []
    priority = 'normal'
    resolution = 'duplicate'
    stage = None
    status = 'closed'
    superseder = '1665'
    type = None
    url = 'https://bugs.python.org/issue1728'
    versions = ['Python 2.5']

    @AstraLuma
    Copy link
    Mannequin Author

    AstraLuma mannequin commented Jan 3, 2008

    Something about distutils/cmd.py breaks inspect.findsource(). I am
    unsure if this is a bug with DistUtils or the inspect module.

    >> import inspect, distutils.cmd
    >> inspect.findsource(distutils.cmd.install_misc.get_outputs)

    Causes findsource() to receive an IndexError.

    From some hacking, I've found that the root cause appears to be that
    linecache.getlines() returns a number of lines that do not match the
    actual file. (In my case, getlines() returns 405 lines when
    distutils/cmd.py has 478 lines.)

    This bug causes pydoc to break when it is pointed at distutils.cmd.

    This is on Ubuntu Gutsy, Python 2.5.1

    @draghuram
    Copy link
    Mannequin

    draghuram mannequin commented Jan 3, 2008

    I can't reproduce it with 2.5.1 on SuSE 10. Can you please report the
    exact traceback you see?

    @AstraLuma
    Copy link
    Mannequin Author

    AstraLuma mannequin commented Jan 3, 2008

    sqlite3/test/types.py also seems to cause the same error, although the
    difference is much wider (101 lines vs. 351).

    @AstraLuma
    Copy link
    Mannequin Author

    AstraLuma mannequin commented Jan 3, 2008

    The exact traceback is as follows:

    >>> findsource(distutils.cmd.install_misc.get_outputs)
    Traceback (most recent call last):
      File "<stdin>", line 1, in <module>
      File "/usr/lib/python2.5/inspect.py", line 510, in findsource
        if pat.match(lines[lnum]): break
    IndexError: list index out of range

    @gvanrossum
    Copy link
    Member

    Can't repro either.

    I strongly suspect that this is because somehow linecache finds a
    different version of the module on sys.path.

    @AstraLuma
    Copy link
    Mannequin Author

    AstraLuma mannequin commented Jan 3, 2008

    Indeed. For the distutils.cmd case, linecache.updatecache() takes
    "cmd.py" and tracks that down to /usr/lib/python2.5/cmd.py. This would
    also explain the sqlite3.tests.types problem.

    The bug seems to be that the inspect module doesn't pass enough context
    information to linecache to unambiguously locate the file.

    @gvanrossum
    Copy link
    Member

    Can you trace this a bit further? Can you suggest a specific
    modification that would fix this issue?

    @draghuram
    Copy link
    Mannequin

    draghuram mannequin commented Jan 3, 2008

    When I printed the file name that is being passed to
    linecache.getlines() by findsource(), the file name is absolute path.
    So there may be nothing wrong with linecache itself. Can you see what
    is the name being passed in your case? We still need to trace what
    specific setting on OP's system is causing the problem.

    @AstraLuma
    Copy link
    Mannequin Author

    AstraLuma mannequin commented Jan 3, 2008

    depending on the use case, updatecache() will be passed
    'distutils/cmd.py', but still turn that into '/usr/lib/python2.5/cmd.py'.

    I have not messed with my stock Python modules. My sys.path is:

    • /usr/lib/python2.5/site-packages/recaptcha_client-1.0.1-py2.5.egg
    • /usr/lib/python25.zip
    • /usr/lib/python2.5/lib-dynload
    • /usr/lib/python2.5/site-packages/Numeric
    • /usr/lib/python2.5/site-packages/PIL
    • /usr/lib/python2.5/site-packages/wx-2.8-gtk2-unicode
    • /usr/lib/python2.5/site-packages
    • /usr/lib/python2.5
    • /usr/lib/python2.5/plat-linux2
    • /usr/lib/python2.5/lib-tk
    • /usr/local/lib/python2.5/site-packages
    • /usr/lib/python2.5/site-packages/gst-0.10
    • /var/lib/python-support/python2.5/pyinotify
    • /var/lib/python-support/python2.5
    • /usr/lib/python2.5/site-packages/gtk-2.0
    • /var/lib/python-support/python2.5/gtk-2.0
    • /usr/lib/site-python

    I've also attached the script I used to discover the bug originally.
    (Much larger than the snippets I've been pasting here.) Just be warned
    that it writes a large number of files and produces considerable output.

    @tiran
    Copy link
    Member

    tiran commented Jan 3, 2008

    The issue is probably related to http://bugs.python.org/issue1665

    @gvanrossum
    Copy link
    Member

    Do you happen to be on Ubuntu?

    Maybe this is the same as issue bpo-1665 ?

    @AstraLuma
    Copy link
    Mannequin Author

    AstraLuma mannequin commented Jan 4, 2008

    They might be the same bug, with different manifestations.

    That bug is starting to get rather annoying.

    (At first, I thought it wasn't. Surprise, surprise.)

    @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
    None yet
    Projects
    None yet
    Development

    No branches or pull requests

    2 participants