Description of problem: A recent package rename[1] has made the ovirt-engine-sdk python package not installable as explained by the ovirt documentation[2]. Renaming packages is extremely rude, and while I see that care was taken[3] to soften the blow for RPM consumers, pypi consumers are left out in the cold to figure this problem out for themselves[4]. [1]: http://gerrit.ovirt.org/gitweb?p=ovirt-engine-sdk.git;a=commitdiff;h=9fe3c24b2e9837119c1ae7b1d82fd32f4c87e808 [2]: http://www.ovirt.org/Python-sdk#Deployment [3]: https://bugzilla.redhat.com/show_bug.cgi?id=1004029 [4]: https://pypi.python.org/pypi/ovirt-engine-sdk Version-Release number of selected component (if applicable): 3.3.0.3 and above How reproducible: Every time. Steps to Reproduce: 1. easy_install ovirt-engine-sdk (See link #2 above) Actual results: $ easy_install ovirt-engine-sdk Searching for ovirt-engine-sdk Reading http://pypi.python.org/simple/ovirt-engine-sdk/ Couldn't find index page for 'ovirt-engine-sdk' (maybe misspelled?) Expected results: $ easy_install ovirt-engine-sdk Searching for ovirt-engine-sdk Best match: ovirt-engine-sdk 3.3.0.6-1 Adding ovirt-engine-sdk 3.3.0.6-1 to easy-install.pth file Using /path/to/site-packages Processing dependencies for ovirt-engine-sdk Finished processing dependencies for ovirt-engine-sdk
Sean, The package rename was announced on the ML, however thanks for reporting this, i've updated the wiki accordingly and restored the old 3.2 ovirt-engine-sdk repo, (though it not relevant to the latest oVirt), as about your "expected results", i've found only two options to rename the package in pypi, 1. submit a support request to the PyPI for rename 2. drop the old repo + add new one (what i initially did) afaiu both will lead to the issues you've mentioned, if you aware of any other option to deliver the new package via old repo, i'd be glad to hear. (just FYI, you can also use tarballs/official releases to install sdk, also ovirt-engine-sdk-python "provides" old ovirt-engine-sdk so you can safely migrate to it)
Sorry for the delay... I want to clarify that this issue is in the context of PyPI. Therefore, the following statements don't really apply: > The package rename was announced on the ML > you can also use tarballs/official releases to install sdk > ovirt-engine-sdk-python "provides" old ovirt-engine-sdk * I don't follow the mailing list, nor do I have any reason to do so as a solely PyPI consumer. * "tarballs/official" doesn't mean anything in the context of PyPI or generic python packaging * While there are facilities to implement "provides" functionality in python packages, they aren't currently being used by the ovirtsdk setup.py (https://github.com/oVirt/ovirt-engine-sdk/blob/master/setup.py) A possible third option is this: 3. Decouple the rpm packaging and python packaging. While it makes sense in the RPM context, the -python suffix is redundant on python's package index. The setup.py in the source repository should reflect the "proper" python name, that being what's in PyPI (ovirt-engine-sdk, NOT ovirt-engine-sdk-python). Any changes that need to occur to make the package be correct in RPM-land should be done in RPM-land (i.e. in the spec file). I understand that the forces of reality might not agree with all of that, but that's how it SHOULD work, in the RFC 2119 sense of the word. Finally, I'll point out that according to PyPI, this issue still affects people. See the download counts on the two related pages: https://pypi.python.org/pypi/ovirt-engine-sdk https://pypi.python.org/pypi/ovirt-engine-sdk-python More people are downloading ovirt-engine-sdk than are downloading ovirt-engine-sdk-python, and due to the now-restored-and-unmaintained package, may never upgrade. That strikes me as suboptimal.
Sean, (In reply to Sean Myers from comment #2) > Sorry for the delay... > > I want to clarify that this issue is in the context of PyPI. Therefore, the > following statements don't really apply: > > > The package rename was announced on the ML > > you can also use tarballs/official releases to install sdk > > ovirt-engine-sdk-python "provides" old ovirt-engine-sdk > > * I don't follow the mailing list, nor do I have any reason to do so as a > solely PyPI consumer. > * "tarballs/official" doesn't mean anything in the context of PyPI or > generic python packaging i'm afraid i disagree with you on this, it's true that ovirt-engine-sdk is hosted at pypi, but this is an upstream project and all changes announcement for it should take place at the appropriate channel (in our case mailing list/wiki) > * While there are facilities to implement "provides" functionality in python > packages, they aren't currently being used by the ovirtsdk setup.py > (https://github.com/oVirt/ovirt-engine-sdk/blob/master/setup.py) true, but AFAIK this specification is not implemented by any tool yet, so it wouldn't help, anyway you're welcome sending a patch :) > > A possible third option is this: > > 3. Decouple the rpm packaging and python packaging. i wouldn't want having different packages installed by rpm and pypi, especially when rpm installation is "Obsoletes: ovirt-engine-sdk" ... > > While it makes sense in the RPM context, the -python suffix is redundant on > python's package index. The setup.py in the source repository should reflect > the "proper" python name, that being what's in PyPI (ovirt-engine-sdk, NOT > ovirt-engine-sdk-python). Any changes that need to occur to make the package > be correct in RPM-land should be done in RPM-land (i.e. in the spec file). and it done there [1] only ... [1] https://github.com/oVirt/ovirt-engine-sdk/blob/master/ovirt-engine-sdk-python.spec.in > > I understand that the forces of reality might not agree with all of that, > but that's how it SHOULD work, in the RFC 2119 sense of the word. > > Finally, I'll point out that according to PyPI, this issue still affects > people. See the download counts on the two related pages: > https://pypi.python.org/pypi/ovirt-engine-sdk > https://pypi.python.org/pypi/ovirt-engine-sdk-python > > More people are downloading ovirt-engine-sdk than are downloading > ovirt-engine-sdk-python, > and due to the now-restored-and-unmaintained > package, may never upgrade. That strikes me as suboptimal. you cannot know that, it could be true cause they downloading sdk for 3.2, no point of having 3.3 sdk (ovirt-engine-sdk-python) on 3.2 with bunch of features that you cannot use.