Description of problem: IPython requires argparse, argparse included in the dependencies list for this package python-ipython-0.13.1-1.fc18.noarch.rpm Version-Release number of selected component (if applicable): 0.13.1 How reproducible: Always for me. Steps to Reproduce: 1. Remove python-argparse 2. Try to install this version of ipython 3. Install succeeds 4. Run Ipython, complains about argparse missing. Actual results: Ipython throws import exception at startup Expected results: Ipython starts normaly Additional info: To fix install python-argparse
Thanks for the bug report. argparse should be available in python itself so there is no need for a python-argparse package: http://docs.python.org/2.7/library/argparse.html#module-argparse How exactly does it fail? Can you provide the backtrace please?
After installing ipython and then starting it like so, I get this traceback. $ ipython Traceback (most recent call last): File "/usr/bin/ipython", line 5, in <module> from IPython.frontend.terminal.ipapp import launch_new_instance File "/usr/lib/python2.6/site-packages/IPython/__init__.py", line 43, in <module> from .config.loader import Config File "/usr/lib/python2.6/site-packages/IPython/config/__init__.py", line 16, in <module> from .application import * File "/usr/lib/python2.6/site-packages/IPython/config/application.py", line 31, in <module> from IPython.config.configurable import SingletonConfigurable File "/usr/lib/python2.6/site-packages/IPython/config/configurable.py", line 26, in <module> from loader import Config File "/usr/lib/python2.6/site-packages/IPython/config/loader.py", line 26, in <module> from IPython.external import argparse File "/usr/lib/python2.6/site-packages/IPython/external/argparse/__init__.py", line 10, in <module> from _argparse import * ImportError: No module named _argparse Argparse is a dependency that doesn't get installed/recognized when installing ipython is what I'm trying to say.
(In reply to comment #2) > After installing ipython and then starting it like so, I get this traceback. > > $ ipython > Traceback (most recent call last): [snip] > "/usr/lib/python2.6/site-packages/IPython/external/argparse/__init__.py", > line 10, in <module> > from _argparse import * > ImportError: No module named _argparse ipython checks, if argparse version is greater than 1.1. What's the output of: $ python -c "import argparse ; print argparse.__version__ ; print argparse.__file__" Furthermore, there is no python 2.6 on f18, there are only python2.7 files around: http://koji.fedoraproject.org/koji/rpminfo?rpmID=3441054 What version are you running at? Can you provide the output of: $ rpm -q python $ rpm -qa | grep ipython > Argparse is a dependency that doesn't get installed/recognized when > installing ipython is what I'm trying to say. Maybe it's the old argparse version or an too old Fedora version, where you tried to install/rebuild the f18 rpm... Needs a bit further tracking down, where the bug actually is.
I rebuilt the fc18 IPython rpm for RHEL 6 since I wanted to use something up to date. $ rpm -q python python-2.6.6-29.el6_3.3.x86_64 $ rpm -qa | grep ipython python-ipython-console-0.13.1-1.el6.noarch python-ipython-0.13.1-1.el6.noarch python-ipython-notebook-0.13.1-1.el6.noarch python-ipython-gui-0.13.1-1.el6.noarch python-ipython-doc-0.13.1-1.el6.noarch python-ipython-tests-0.13.1-1.el6.noarch
Aha, I assume, you're stumbling upon your old python version and PEP-389, introduced in python-2.7: http://docs.python.org/2/whatsnew/2.7.html#pep-389-the-argparse-module-for-parsing-command-lines
and also: on rhel6: [mrunge@rhel6 ~]$ rpm -q python-argparse python-argparse-1.2.1-2.el6.noarch [mrunge@rhel6 ~]$ python Python 2.6.6 (r266:84292, Aug 28 2012, 10:55:56) [GCC 4.4.6 20120305 (Red Hat 4.4.6-4)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import argparse versus: [mrunge@turing fedora]$ rpm -q python-argparse package python-argparse is not installed [mrunge@turing fedora]$ python Python 2.7.3 (default, Jul 24 2012, 10:05:38) [GCC 4.7.0 20120507 (Red Hat 4.7.0-5)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import argparse So, I can't see anything wrong in this package.
I'd take this bug as an update request on el6 (as that's you intention with locally rebuilding the Fedora package). You need to add yourself the "Requires: python-argparse" line yourself locally as it is not applicable for Fedora (and was in fact removed by intention some time ago).
ipython-0.10-3.el6 has been submitted as an update for Fedora EPEL 6. https://admin.fedoraproject.org/updates/ipython-0.10-3.el6
Package ipython-0.10-3.el6: * should fix your issue, * was pushed to the Fedora EPEL 6 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=epel-testing ipython-0.10-3.el6' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-EPEL-2013-0875/ipython-0.10-3.el6 then log in and leave karma (feedback).
The installation works great, but when I tried to run qtconsole, I get the error: "the sip module implements API v9.0 to v9.2 but the PyQt4.QtCore module requires API v6.0"
ipython-0.10-3.el6 has been pushed to the Fedora EPEL 6 stable repository. If problems still persist, please make note of it in this bug report.
this is what I did to resolve the dependencies on rhel5.9: [root@hangtough ~]# yum install *argparse* Loaded plugins: product-id, rhnplugin, security This system is receiving updates from RHN Classic or RHN Satellite. Setting up Install Process Resolving Dependencies --> Running transaction check ---> Package python-argparse.noarch 0:1.2.1-2.el5 set to be updated ---> Package python26-argparse.noarch 0:1.2.1-3.el5 set to be updated --> Processing Dependency: python26 for package: python26-argparse --> Running transaction check ---> Package python26.i386 0:2.6.8-2.el5 set to be updated --> Processing Dependency: libpython2.6.so.1.0 for package: python26 --> Processing Dependency: libffi.so.5 for package: python26 --> Running transaction check ---> Package libffi.i386 0:3.0.5-1.el5 set to be updated ---> Package python26-libs.i386 0:2.6.8-2.el5 set to be updated --> Finished Dependency Resolution Dependencies Resolved ======================================================================================================= Package Arch Version Repository Size ======================================================================================================= Installing: python-argparse noarch 1.2.1-2.el5 epel 73 k python26-argparse noarch 1.2.1-3.el5 epel 71 k Installing for dependencies: libffi i386 3.0.5-1.el5 epel 21 k python26 i386 2.6.8-2.el5 epel 6.5 M python26-libs i386 2.6.8-2.el5 epel 670 k Transaction Summary ======================================================================================================= Install 5 Package(s) Upgrade 0 Package(s) Total download size: 7.3 M Is this ok [y/N]: y Downloading Packages: (1/5): libffi-3.0.5-1.el5.i386.rpm | 21 kB 00:00 (2/5): python26-argparse-1.2.1-3.el5.noarch.rpm | 71 kB 00:00 (3/5): python-argparse-1.2.1-2.el5.noarch.rpm | 73 kB 00:00 (4/5): python26-libs-2.6.8-2.el5.i386.rpm | 670 kB 00:00 (5/5): python26-2.6.8-2.el5.i386.rpm | 6.5 MB 00:04 ------------------------------------------------------------------------------------------------------- Total 1.1 MB/s | 7.3 MB 00:06 warning: rpmts_HdrFromFdno: Header V3 DSA signature: NOKEY, key ID 217521f6 epel/gpgkey | 1.7 kB 00:00 Importing GPG key 0x217521F6 "Fedora EPEL <epel>" from /etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL Is this ok [y/N]: y Running rpm_check_debug Running Transaction Test Finished Transaction Test Transaction Test Succeeded Running Transaction Installing : python-argparse 1/5 Installing : libffi 2/5 Installing : python26 3/5 Installing : python26-libs 4/5 Installing : python26-argparse 5/5 Installed: python-argparse.noarch 0:1.2.1-2.el5 python26-argparse.noarch 0:1.2.1-3.el5 Dependency Installed: libffi.i386 0:3.0.5-1.el5 python26.i386 0:2.6.8-2.el5 python26-libs.i386 0:2.6.8-2.el5 Complete!
Not sure how this is marked resolved, but the current version of ipython seems to have dropped this dependency: # rpm -q --requires python-ipython-console /usr/bin/python pexpect python(abi) = 2.6 python-mglob python-setuptools python-simplegeneric python-zmq rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(FileDigests) <= 4.6.0-1 rpmlib(PartialHardlinkSets) <= 4.0.4-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rpmlib(PayloadIsXz) <= 5.2-1 Of course, as an experienced python user I was able to immediately tell what the problem was and fix it. But overall it makes for a pretty terrible user experience.
# rpm -qa | fgrep ipython python-ipython-0.13.2-5.el6.noarch python-ipython-console-0.13.2-5.el6.noarch python-ipython-gui-0.13.2-5.el6.noarch python-ipython-notebook-0.13.2-5.el6.noarch
This was a build that fixed this when the ipython package in EPEL-6 was at ipython-0.10, but then we rebased it and it looks like this problem came back. During the rebase, it looks either I or Tomas changed the 'Requires: python-argparse' to 'BuildRequires: python-argparse'. I honestly can't remember the entire process of rebasing this package, I just remember rebasing it being something we wanted to do. I can add back an explicit Requires and build a new testing update.
Oh wait, I remember. I grabbed a newer ipython from pkg-git to backport. The Requires for python-argparse was gone because as of Python 2.7, that's now included in the Python release. And since EL-6 is on Python 2.6, we need to require that. Now it's all coming back.
(In reply to David Cantrell from comment #16) > This was a build that fixed this when the ipython package in EPEL-6 was at > ipython-0.10, but then we rebased it and it looks like this problem came > back. > > During the rebase, it looks either I or Tomas changed the 'Requires: > python-argparse' to 'BuildRequires: python-argparse'. I honestly can't > remember the entire process of rebasing this package, I just remember > rebasing it being something we wanted to do. > > I can add back an explicit Requires and build a new testing update. Yes, please do so. The problem still persists.
ipython-0.13.2-6.el6 has been submitted as an update for Fedora EPEL 6. https://admin.fedoraproject.org/updates/ipython-0.13.2-6.el6
Package ipython-0.13.2-6.el6: * should fix your issue, * was pushed to the Fedora EPEL 6 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=epel-testing ipython-0.13.2-6.el6' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-EPEL-2015-1208/ipython-0.13.2-6.el6 then log in and leave karma (feedback).
(In reply to Fedora Update System from comment #20) > Package ipython-0.13.2-6.el6: > * should fix your issue, > * was pushed to the Fedora EPEL 6 testing repository, > * should be available at your local mirror within two days. > Update it with: > # su -c 'yum update --enablerepo=epel-testing ipython-0.13.2-6.el6' > as soon as you are able to. > Please go to the following url: > https://admin.fedoraproject.org/updates/FEDORA-EPEL-2015-1208/ipython-0.13.2- > 6.el6 > then log in and leave karma (feedback). Thank you for this very clear explanation. I think I was wondering for five years or more, what it means exactly, when the expert says "I pushed the solution." and nothing improved on my system(s).
We have a complex process of code-to-rpm before end users see fixes. I'm glad this comment helped explain some of that. Generally, "push" means that the developer has committed a change somewhere in version control. That's the first step. The next step is to produce a "build". That's the group of RPM packages for each architecture for the release in question. The step after that is to prepare an "update" in the updates system. The update is some paperwork along with those built packages. Once we complete that, the updates system moves the packages to the "testing" phase where the package is available to you in the appropriate testing repo. The instructions above indicate how you can install those. We let the update sit in testing for 2 weeks hoping to hear feedback from the reporter as to whether or not the update actually worked for them. I never hear back from the reporters during this time, so eventually 15 days later I just push the update to stable and then I hear things. :) I hear people a lot asking about how updates are made and what the different parts of the process are. Perhaps a writeup on the Fedora Magazine site would be helpful for others.
(In reply to David Cantrell from comment #22) Thanks again for your very complete answer. > I > never hear back from the reporters during this time, so eventually 15 days > later I just push the update to stable and then I hear things. :) This gets slightly off-topic within this ticket. But I (as an occasional reporter, who most oftenly gets frustrated, because 75% of his reports hit the end-of-support line are never considered) think that there is a real communication problem, as reporters (assuming that occasional reporters are the majority) do not know what they can do and how, once the issue has been addressed by the experts. That in turn may lead to frustration among the experts obviously. > I hear people a lot asking about how updates are made and what the different > parts of the process are. Perhaps a writeup on the Fedora Magazine site > would be helpful for others. Ideally I would see a link from bugzilla to a concise list of steps of the procedure, close to the "Status" field below or even as a function of the actual ticket status "What is supposed to happen next?". Can you split off this topic from the present ticket to continue discussion? (I would know how to do it on redmine, which I use on a daily basis.) Consider the following: Many occasional users of redhat bugzilla will know how the bug-report-repair-feedback-implement process works in principle, from their own project and daily/regular work. But the details and the tools are just obscure boxes to them. If that threshold ("I know what should happen, but not how I can do it.") could be lowered, you may gain a lot for everyone's comfort. PS: I did not even know that Fedora Magazine exists, even less where to find it. (Read: I would rule that solution out ;-) Thanks again for your encouraging explanations.
Sure, moving the discussion to email. Can you check the update in comment #20 to see if it fixes the problem for you? If it does, I can push this to stable. Thanks.
(In reply to David Cantrell from comment #24) > Sure, moving the discussion to email. Can you check the update in comment > #20 to see if it fixes the problem for you? If it does, I can push this to > stable. Should we worry about this? $ sudo yum update --enablerepo=epel-testing ipython-0.13.2-6.el6 Loaded plugins: refresh-packagekit, security Setting up Update Process No Match for argument: ipython-0.13.2-6.el6 No package ipython-0.13.2-6.el6 available. No Packages marked for Update However I get exactly that package when I do not tell yum the version number: $ sudo yum update --enablerepo=epel-testing ipython Loaded plugins: refresh-packagekit, security Setting up Update Process Resolving Dependencies --> Running transaction check ---> Package python-ipython.noarch 0:0.13.2-5.el6 will be updated ---> Package python-ipython.noarch 0:0.13.2-6.el6 will be an update --> Processing Dependency: python-ipython-notebook = 0.13.2-6.el6 for package: python-ipython-0.13.2-6.el6.noarch --> Processing Dependency: python-ipython-gui = 0.13.2-6.el6 for package: python-ipython-0.13.2-6.el6.noarch --> Processing Dependency: python-ipython-console = 0.13.2-6.el6 for package: python-ipython-0.13.2-6.el6.noarch --> Running transaction check ---> Package python-ipython-console.noarch 0:0.13.2-5.el6 will be updated ---> Package python-ipython-console.noarch 0:0.13.2-6.el6 will be an update ---> Package python-ipython-gui.noarch 0:0.13.2-5.el6 will be updated ---> Package python-ipython-gui.noarch 0:0.13.2-6.el6 will be an update ---> Package python-ipython-notebook.noarch 0:0.13.2-5.el6 will be updated ---> Package python-ipython-notebook.noarch 0:0.13.2-6.el6 will be an update --> Finished Dependency Resolution Dependencies Resolved ================================================================================ Package Arch Version Repository Size ================================================================================ Updating: python-ipython noarch 0.13.2-6.el6 epel-testing 11 k Updating for dependencies: python-ipython-console noarch 0.13.2-6.el6 epel-testing 1.3 M python-ipython-gui noarch 0.13.2-6.el6 epel-testing 165 k python-ipython-notebook noarch 0.13.2-6.el6 epel-testing 319 k Transaction Summary ================================================================================ Upgrade 4 Package(s) Total download size: 1.7 M Is this ok [y/N]: y [... etc.] It works fine (does as expected, I think): $ yum list python-ipython Loaded plugins: refresh-packagekit, security Installed Packages python-ipython.noarch 0.13.2-6.el6 @epel-testing But I still do not see python-argparse in the dependencies list: $ rpm -qa | fgrep ipython python-ipython-gui-0.13.2-6.el6.noarch python-ipython-notebook-0.13.2-6.el6.noarch python-ipython-console-0.13.2-6.el6.noarch python-ipython-0.13.2-6.el6.noarch And this ... $ sudo yum remove python-argparse Loaded plugins: refresh-packagekit, security Setting up Remove Process Resolving Dependencies --> Running transaction check ---> Package python-argparse.noarch 0:1.2.1-2.el6 will be erased --> Finished Dependency Resolution Dependencies Resolved ================================================================================ Package Arch Version Repository Size ================================================================================ Removing: python-argparse noarch 1.2.1-2.el6 @epel 232 k Transaction Summary ================================================================================ Remove 1 Package(s) Installed size: 232 k Is this ok [y/N]: [... etc.] Breaks ipython (python-ipython): $ ipython Traceback (most recent call last): File "/usr/bin/ipython", line 5, in <module> from IPython.frontend.terminal.ipapp import launch_new_instance File "/usr/lib/python2.6/site-packages/IPython/__init__.py", line 43, in <module> from .config.loader import Config File "/usr/lib/python2.6/site-packages/IPython/config/__init__.py", line 16, in <module> from .application import * File "/usr/lib/python2.6/site-packages/IPython/config/application.py", line 31, in <module> from IPython.config.configurable import SingletonConfigurable File "/usr/lib/python2.6/site-packages/IPython/config/configurable.py", line 26, in <module> from loader import Config File "/usr/lib/python2.6/site-packages/IPython/config/loader.py", line 26, in <module> from IPython.external import argparse File "/usr/lib/python2.6/site-packages/IPython/external/argparse/__init__.py", line 10, in <module> from _argparse import * ImportError: No module named _argparse Sorry! Same player shoots again ;-)
Additional info on my first question: $ sudo yum update --enablerepo=epel-testing python-ipython-0.13.2-6.el6 Loaded plugins: refresh-packagekit, security Setting up Update Process No Packages marked for Update I.e. works with "python-ipython-...", but not "ipython-...". Is there such a thing as aliasing package names with yum? There may be a mismatch then, or the aliased package name simply cannot be used with version number. (It's a feature!)
Remark: In the meantime I understood that newer python versions (>2.7 and >3.2 ?) have argparse included in the standard library, which may be the reason that python-ipython does not require python-argparse explicitely, or at least not as RPM package.
*** Bug 1206495 has been marked as a duplicate of this bug. ***
ipython-0.13.2-6.el6 has been pushed to the Fedora EPEL 6 stable repository. If problems still persist, please make note of it in this bug report.
(In reply to Fedora Update System from comment #29) > ipython-0.13.2-6.el6 has been pushed to the Fedora EPEL 6 stable repository. > If problems still persist, please make note of it in this bug report. So you pushed a version that is reported not to work on epel-testing to epel stable. Why should that work now? I confirm that all commands as mentioned in comment #25 yield exactly the same results without "--enablerepo=epel-testing". I am sorry, but it starts to become frustrating that this problem, which seems to be a matter of adding the right line for a dependency in the RPM spec file, cannot be solved more efficiently.
*** Bug 1111941 has been marked as a duplicate of this bug. ***