RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 924038 - python-pip install keyring fails first time
Summary: python-pip install keyring fails first time
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: python-setuptools
Version: 6.4
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Python Maintainers
QA Contact: BaseOS QE - Apps
URL:
Whiteboard:
Depends On:
Blocks: 922920
TreeView+ depends on / blocked
 
Reported: 2013-03-21 02:25 UTC by Ian Wienand
Modified: 2016-07-15 08:43 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-07-15 08:43:09 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
Full log from install (4.77 KB, text/plain)
2013-03-21 02:25 UTC, Ian Wienand
no flags Details
log from second run, where install works (404 bytes, text/plain)
2013-03-21 02:28 UTC, Ian Wienand
no flags Details

Description Ian Wienand 2013-03-21 02:25:00 UTC
Created attachment 713574 [details]
Full log from install

Description of problem:

"pip-python install keyring" on a fresh rhel6.4 install fails the first time, but works the second time 

How reproducible:

alwyas

Steps to Reproduce:

pip-python install keyring
  
Actual results:

it bails with an error 

---
Downloading/unpacking keyring
  Downloading keyring-1.2.2.zip (79Kb): 79Kb downloaded
  Running setup.py egg_info for package keyring
    zip_safe flag not set; analyzing archive contents...
    
    Installed /tmp/easy_install-u0ESXQ/pytest-runner-1.2/hgtools-2.0.3-py2.6.egg
    
    Installed /root/build/keyring/pytest_runner-1.2-py2.6.egg
    Traceback (most recent call last):
      File "<string>", line 14, in <module>
      File "/root/build/keyring/setup.py", line 114, in <module>
        setup_mod.setup(**setup_params)
      File "/usr/lib64/python2.6/distutils/core.py", line 152, in setup
        dist.run_commands()
      File "/usr/lib64/python2.6/distutils/dist.py", line 975, in run_commands
        self.run_command(cmd)
      File "/usr/lib64/python2.6/distutils/dist.py", line 995, in run_command
        cmd_obj.run()
      File "<string>", line 12, in replacement_run
      File "/usr/lib/python2.6/site-packages/setuptools/command/egg_info.py", line 254, in find_sources
        mm.run()
      File "/usr/lib/python2.6/site-packages/setuptools/command/egg_info.py", line 308, in run
        self.add_defaults()
      File "/usr/lib/python2.6/site-packages/setuptools/command/egg_info.py", line 335, in add_defaults
        rcfiles = list(walk_revctrl())
      File "/usr/lib/python2.6/site-packages/setuptools/command/sdist.py", line 46, in walk_revctrl
        for item in ep.load()(dirname):
      File "/usr/lib/python2.6/site-packages/pkg_resources.py", line 1948, in load
        entry = __import__(self.module_name, globals(),globals(), ['__name__'])
    ImportError: No module named hgtools.plugins
    Complete output from command python setup.py egg_info:
    zip_safe flag not set; analyzing archive contents...
---


Expected results:

it installs


Additional info:

Comment 1 Ian Wienand 2013-03-21 02:28:33 UTC
Created attachment 713575 [details]
log from second run, where install works

Comment 2 Ian Wienand 2013-03-21 03:31:56 UTC
It really gets down into the weeds of setuptools, but I have an inkling the problem comes from the dependency in pytest-runner [1], which has a file ".hgtags" in it's zip.

[1] https://pypi.python.org/packages/source/p/pytest-runner/pytest-runner-1.2.zip

Comment 3 Ian Wienand 2013-04-30 05:25:13 UTC
So here's the problem in a nutshell

keyring -> pytest-runner -> hgtools

hgtools is a "setup_requires" dependency for pytest-runner.  This
means the following code is run:

/usr/lib/python2.6/site-packages/setuptools/dist.py

---
class Distribution(_Distribution):
    def __init__():
     ...
        if attrs and 'setup_requires' in attrs:
            self.fetch_build_eggs(attrs.pop('setup_requires'))

    def fetch_build_eggs(self, requires):
        """Resolve pre-setup requirements"""
        from pkg_resources import working_set, parse_requirements
        for dist in working_set.resolve(
            parse_requirements(requires), installer=self.fetch_build_egg
        ):
            working_set.add(dist)
---

That goes fine, hgtools gets installed

---
  Running setup.py egg_info for package keyring
    zip_safe flag not set; analyzing archive contents...
    
    Installed /tmp/easy_install-QgHJjS/pytest-runner-1.2/hgtools-3.0.2-py2.6.egg
    
    Installed /root/build/keyring/pytest_runner-1.2-py2.6.egg
---

The temporary hgtools (via easy_install) has registered some entry
points with its distribution object in working_set.  However, it then
disappears but doesn't remove itself.  Later on in sdist.py we have

---
def walk_revctrl(dirname=''):
    """Find all files under revision control"""
    for ep in pkg_resources.iter_entry_points('setuptools.file_finders'):
        for item in ep.load()(dirname):
            yield item
----

pkg_resources.iter_entry_points walks working_set, finds hgtools'
entry points for this file_finders stuff, tries to call it and a
backtrace ensues because that temporary directory with hgtools has now
gone.

This also explains why it works when run the second time around;
pytest-runner is already there, so we don't need to looking at its
setup_requires and the problematic distribution doesn't get added.

Somehow or other, hgtools needs to get removed from the working_set in
dist.py before it is removed?

Comment 4 Ian Wienand 2013-04-30 06:09:03 UTC
I have reported this upstream with 

http://bugs.python.org/setuptools/issue148

Comment 6 Michal Hlavinka 2013-04-30 08:14:04 UTC
wrong component, changing to python-setuptools

Comment 7 Ian Wienand 2013-04-30 22:24:04 UTC
Thanks to some help from the upstream bug, I now realise that rhel6.4 python-seutptools is distribute 0.6.10.  There are a series of patches attached to [1] which may be the solution to this.  Upstream bug mentions 0.6.19 was about the version it was fixed.

I confirmed that removing python-setuptools, installing upstream distribute (0.6.36) and then installing python-pip from epel with --nodeps does install keyring properly.  so it has been fixed at some point between 0.6.10 -> 0.6.36...

[1] https://bitbucket.org/tarek/distribute/issue/205/distributes-sandboxing-doesnt-preserve

Comment 8 RHEL Program Management 2013-10-13 23:47:05 UTC
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated
in the current release, Red Hat is unable to address this
request at this time.

Red Hat invites you to ask your support representative to
propose this request, if appropriate, in the next release of
Red Hat Enterprise Linux.

Comment 9 Bohuslav "Slavek" Kabrda 2014-02-14 12:53:24 UTC
Note: Link to the patch that fixes the issue: https://bitbucket.org/tarek/distribute/commits/856cd8712941d37257f8ef1d768564ad0e49e90a?at=fix-sdist


Note You need to log in before you can comment on or make changes to this bug.