Conflicting binaries installed by tempest and tempest-lib

[Luigi Toscano]

After that the content of tempest-lib has been merged back into tempest (>=10), the two programs check-uuid and skip-tracker are provided by both packages.
From a pip point of view, it seems that the first package installed "wins", which is not the desired behavior.

Possible resolutions:
a) rename the binaries in tempest-lib, release a final 1.0.1. Drawback: the users of those programs (== code which need to be ported away from tempest-lib) won't find them anymore.
b) remove the binaries from tempest-lib, make tempest-lib dependent on tempest, release 1.0.1. A bit complicated, but basically all users of tempest-lib (tests) likely need tempest for discoverability, so the last version of the programs will be provided without breaking the dependencies. This assume that the behavior of those programs is not going to change (at least not until tempest-lib is useless)
c) rename the binaries in tempest, so that the problem of using them is part of "migrate away from tempest-lib". Possible issue: a version of tempest providing those programs has been released already (but it's possible to add the required dependencies back).
d) just document the issue. But this is the same as doing nothing, as it does not prevent the wrong programs from being installed.

[Ken'ichi Ohmichi (oomichi)]

I am a little confused here.
The library paths are different between tempest.lib (Tempest's) and tempest_lib (tempest-lib's).
Why the conflict happens?

[Luigi Toscano (ltoscano)]

The problem is not about the libraries, but the two executables, which have the same entry_point:

tempest:
[entry_points]
console_scripts =
    [...]
    skip-tracker = tempest.lib.cmd.skip_tracker:main
    check-uuid = tempest.lib.cmd.check_uuid:run

tempest-lib:
[entry_points]
console_scripts =
    skip-tracker = tempest_lib.cmd.skip_tracker:main
    check-uuid = tempest_lib.cmd.check_uuid:run

In both cases the scripts are installed in the bin/ directory (of the virtualenv or whatever is the proper one of the system, like /usr/bin).

[Ken'ichi Ohmichi (oomichi)]

I see, thanks for your explanation.
Tempest side continues growing and Tempest should win in any case.

[Jordan Pittier (jordan-pittier)]

As tempest-lib is history and we can"t do anything about it anymore, I am closing this one.

[Jordan Pittier (jordan-pittier)]

For, the record it was an actual bug. Thanks for reporting.

[Luigi Toscano (ltoscano)]

Do you mean that there are no more users of the separate tempest-lib in the new ocata branches (and hopefully in newton too)?

[Ghanshyam Mann (ghanshyammann)]

@Luigi - Yes, tempest-lib is deprecated lib and should not be used. tempest package provides all interface which were present in tempest-lib.

We do have notes in doc about it. Is there any specific reason of using tempest-lib along with tempest package ? and based on that we can resolve this issue.

"As of the 1.0.0 release tempest-lib as a separate repository and project is deprecated. The library now exists as part of the tempest project, all future development will occur there. To use the library for future releases update your imports from tempest_lib to tempest.lib, and add tempest>=10 to your project requirements"

[Luigi Toscano (ltoscano)]

I know that tempest-lib is deprecated. When I filed this bug, and for a good time afterwards, many packages still required it and people could end up installing both tempest-lib and tempest (with tempest.lib), with the same set of tools.
So the question is not whether there is specific reason for using tempest-lib (there is none) but whether there are still people using it. The answer to the latter seems to be 'not in relevant places' (but see http://codesearch.openstack.org/?q=tempest-lib&i=nope&files=&repos=) , I was just asking for a second confirmation than my search.