The flask python module has some software dependencies which are not reflected by the current rpm package. First remove the installed packages if needed: # urpme python-jinja2 python-werkzeug python-itsdangerous then invoke python and try to import flask: $ python >>> import flask Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/usr/lib/python2.7/site-packages/flask/__init__.py", line 17, in <module> from werkzeug.exceptions import abort ImportError: No module named werkzeug.exceptions >>> Install python-werkzeug and try again. This time python will complain about jinja2 not being installed. Install python-jinja2 and try again. Python will complain about itsdangerous missing. Install python-itsdangerous and try again: it should work (unless there are more dependencies which are already installed on my computer).
Source RPM: (none) => python-flaskKeywords: (none) => Junior_job, TriagedAssignee: bugsquad => mageia
Note that this bug *may* reveal a broader issue with python packages. The package builder should probably auto-detect these dependencies and add them to the rpm package automatically. I've noticed other problems with python packages. For example, the python-jinja2 has the following requirements: # rpm -qp --requires python-jinja2-2.7.3-1.mga5.noarch.rpm python-babel >= 0.8 python-markupsafe rpmlib(PartialHardlinkSets) <= 4.0.4-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rpmlib(CompressedFileNames) <= 3.0.4-1 python(abi) = 2.7 pythonegg(2)(markupsafe) rpmlib(PayloadIsXz) <= 5.2-1 Note that the markupsafe module is added both manually (I guess) as âpython-markupsafeâ, and automatically as âpythonegg(2)(markupsafe)â. Yet the markupsafe package provides the following: # rpm -qp --provides python-markupsafe-0.23-2.mga5.x86_64.rpm python-markupsafe = 0.23-2.mga5 python-markupsafe(x86-64) = 0.23-2.mga5 So right now the python-jinja2 package has a missing dependency. If it is true that the automatic dependency finder is broken for python modules, this may not be a junior job and it should probably be fixed before the final release. Honestly I have no idea if this is true or not. There are many more problems. (For example, as far as I can tell, the rpmdrake package dependencies are broken too.) As soon as the first beta is released, I will reinstall the system on my computer and I will report python dependency issues I run into.
The python automatically generated dependencies were in fact broken in Cauldron, but if I understand correctly, they have been fixed. Is this bug still valid?
CC: (none) => makowski.mageia, thierry.vignaud
Yes, as far as I can tell, the bug is still valid. The current python-flask package (0.10.1-6.mga5, build on Sep 27) basically has no module dependency at all: $ rpm -q --requires python-flask python(abi) = 2.7 rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(PartialHardlinkSets) <= 4.0.4-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rpmlib(PayloadIsXz) <= 5.2-1 $ It should have at least a few egg dependencies. I tried to rebuild the package locally and the dependencies were still not found, which would suggest the dependency scanner is still broken somehow.
(In reply to Johnny from comment #3) > It should have at least a few egg dependencies. I tried to rebuild the > package locally and the dependencies were still not found, which would > suggest the dependency scanner is still broken somehow. it seems yes, under Mga4 we have : Provides python-flask = 0.10.1-3.mga4 pythonegg(2)(flask) = 0.10.1 Requires rpmlib(PartialHardlinkSets) <= 4.0.4-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rpmlib(CompressedFileNames) <= 3.0.4-1 python(abi) = 2.7 pythonegg(2)(itsdangerous) >= 0.21 pythonegg(2)(jinja2) >= 2.4 pythonegg(2)(werkzeug) >= 0.7 rpmlib(PayloadIsXz) <= 5.2-1 under Mag5 we have : Provides python-flask = 0.10.1-6.mga5 pythonegg(2)(flask) = 0.10.1 Requires python(abi) = 2.7 rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(PartialHardlinkSets) <= 4.0.4-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1 rpmlib(PayloadIsXz) <= 5.2-1 Thierry, any clue ?
Assignee: mageia => thierry.vignaud
The egg generated is correct, so it is our mga5 findrequires process that is broken $ cat Flask-0.10.1-py2.7.egg-info/requires.txt Werkzeug>=0.7 Jinja2>=2.4 itsdangerous>=0.21
Blocks: (none) => 14069
Summary: Missing dependencies for python-flask => Missing dependencies for python modules
Source RPM: python-flask => rpm
Keywords: Junior_job, Triaged => (none)Assignee: thierry.vignaud => bugsquad
Looking at /usr/lib/rpm/fileattrs/pythoneggs.attr I wonder how we even get the provides. %__pythoneggs_provides %{_rpmconfigdir}/mageia/pythoneggs.py --provides %__pythoneggs_requires %{_rpmconfigdir}/mageia/pythoneggs.py --requires %__pythoneggs_path ^((/usr/lib(64)?/python[[:digit:]]\\.[[:digit:]]/.*\\.(py[oc]?|egg.*))|(%{_bindir}/python[[:digit:]]\\.[[:digit:]]))$ %__pythoneggs_magic [Pp]ython.*(executable|byte-compiled) So it only wants python executables byte-compiled files. Maybe this is misleading and it is also called on directories which is why we get provides. The problem is that pythoneggs.py expects to be called on a file inside that directory, not the directory itself so it does not create properly the Metadata object. I'll try to patch it.
CC: (none) => pterjan
Committed to git and created a new release. [pterjan@chopin-cauldron-64 python-flask]$ rpmdiff -iT /distrib/cauldron/x86_64/media/core/release/python-flask-0.10.1-6.mga5.noarch.rpm RPMS/noarch/python-flask-0.10.1-6.mga5.noarch.rpm added REQUIRES pythonegg(2)(itsdangerous) >= 0.21 added REQUIRES pythonegg(2)(jinja2) >= 2.4 added REQUIRES pythonegg(2)(werkzeug) >= 0.7 S.5........ /usr/lib/python2.7/site-packages/flask/helpers.pyc S.5........ /usr/lib/python2.7/site-packages/flask/helpers.pyo
Thanks! It may be a good idea to force a rebuild of all standalone python-module packages. I know at least one other package which has broken dependencies (python-livestreamer, which has a missing dependency on python-singledispatch) but there may be many more. As I mentioned in my comment #1, I will reinstall the system on my computer as soon as the first beta is released and I will report the missing dependencies I'll stumble upon, but I will obviously be able to test only a fraction of all available packages. It would be safest to rebuild all module packages in my opinion.
fixed
Status: NEW => RESOLVEDResolution: (none) => FIXED
I noticed a new package that has a broken python dependency: iep (source package: iep-3.5-1.mga5.src.rpm). Installing and running âiepâ throws an import exception for the sip module. $ iep Started our command server /usr/bin/python3: Error while finding spec for 'iep.__main__' (<class 'ImportError'>: No module named 'sip'); 'iep' is a package and cannot be directly executed which is fixed by installing python3-sip. Should I open a new bug for this or could it be considered this dependency should have been found by the package builder? The message looks different from usual python import exceptions so my guess is that it is a new bug.
(In reply to Johnny Accot from comment #10) > I noticed a new package that has a broken python dependency: iep (source > package: iep-3.5-1.mga5.src.rpm). Installing and running âiepâ throws an > import exception for the sip module. > > $ iep > Started our command server > /usr/bin/python3: Error while finding spec for 'iep.__main__' (<class > 'ImportError'>: No module named 'sip'); 'iep' is a package and cannot be > directly executed > > which is fixed by installing python3-sip. Should I open a new bug for this > or could it be considered this dependency should have been found by the > package builder? The message looks different from usual python import > exceptions so my guess is that it is a new bug. you have to report this against iep package, it is specific to this package
> I noticed a new package that has a broken python dependency: iep (source package: iep-3.5-1.mga5.src.rpm). Installing and running âiepâ throws an import exception for the sip module. Thanks for the report Johnny. It should now be fixed in iep-3.5-2.mga5. As Philippe pointed out, don't hesitate to create a specific bug report against the affected package in such cases (well, next time, since hopefully now iep is fixed).
CC: (none) => remi