Bug 1004872 - ovirt-engine-sdk uninstallable
ovirt-engine-sdk uninstallable
Status: CLOSED DEFERRED
Product: oVirt
Classification: Community
Component: ovirt-engine-sdk (Show other bugs)
3.3
Unspecified Unspecified
unspecified Severity medium
: ---
: 4.0.0
Assigned To: Juan Hernández
bugs@ovirt.org
infra
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-09-05 11:59 EDT by Sean Myers
Modified: 2014-03-25 11:20 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-03-25 11:20:17 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Sean Myers 2013-09-05 11:59:00 EDT
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
Comment 1 Michael Pasternak 2013-09-11 06:19:32 EDT
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)
Comment 2 Sean Myers 2013-10-02 18:43:08 EDT
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.
Comment 3 Michael Pasternak 2013-10-03 08:23:19 EDT
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.

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