Bug 1654677 - tx does not work due to dependency on "python-slugify==1.2.6", but 1.2.1 provided
Summary: tx does not work due to dependency on "python-slugify==1.2.6", but 1.2.1 prov...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: transifex-client
Version: 28
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Luis Bazan
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-11-29 12:04 UTC by Tim Landscheidt
Modified: 2018-12-10 23:19 UTC (History)
4 users (show)

Fixed In Version: transifex-client-0.13.5-5.fc29
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-12-06 03:56:49 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Tim Landscheidt 2018-11-29 12:04:58 UTC
When tx is run, it fails when it discovers that F28 provides python-slugify=1.2.1:

| [tim@passepartout ~]$ tx
| Traceback (most recent call last):
|   File "/usr/lib/python3.6/site-packages/pkg_resources/__init__.py", line 570, in _build_master
|     ws.require(__requires__)
|   File "/usr/lib/python3.6/site-packages/pkg_resources/__init__.py", line 888, in require
|     needed = self.resolve(parse_requirements(requirements))
|   File "/usr/lib/python3.6/site-packages/pkg_resources/__init__.py", line 779, in resolve
|     raise VersionConflict(dist, req).with_context(dependent_req)
| pkg_resources.ContextualVersionConflict: (python-slugify 1.2.1 (/usr/lib/python3.6/site-packages), Requirement.parse('python-slugify==1.2.6'), {'transifex-client'})

| During handling of the above exception, another exception occurred:

| Traceback (most recent call last):
|   File "/usr/bin/tx", line 6, in <module>
|     from pkg_resources import load_entry_point
|   File "/usr/lib/python3.6/site-packages/pkg_resources/__init__.py", line 3095, in <module>
|     @_call_aside
|   File "/usr/lib/python3.6/site-packages/pkg_resources/__init__.py", line 3079, in _call_aside
|     f(*args, **kwargs)
|   File "/usr/lib/python3.6/site-packages/pkg_resources/__init__.py", line 3108, in _initialize_master_working_set
|     working_set = WorkingSet._build_master()
|   File "/usr/lib/python3.6/site-packages/pkg_resources/__init__.py", line 572, in _build_master
|     return cls._build_from_requirements(__requires__)
|   File "/usr/lib/python3.6/site-packages/pkg_resources/__init__.py", line 585, in _build_from_requirements
|     dists = ws.resolve(reqs, Environment())
|   File "/usr/lib/python3.6/site-packages/pkg_resources/__init__.py", line 774, in resolve
|     raise DistributionNotFound(req, requirers)
| pkg_resources.DistributionNotFound: The 'python-slugify==1.2.6' distribution was not found and is required by transifex-client
| [tim@passepartout ~]$ rpm -q python3-slugify transifex-client 
| python3-slugify-1.2.1-5.fc28.noarch
| transifex-client-0.13.5-1.fc28.noarch
| [tim@passepartout ~]$

The direct cause of this is that requirements.txt is very specific:

| urllib3<1.24
| six==1.11.0
| requests>=2.19.1,<3.0.0
| python-slugify==1.2.6

whereas transifex-client.spec is not:

| Requires:       python3-setuptools
| BuildRequires:  python3-devel
| Requires:       python3
| Requires:       python3-urllib3
| Requires:       python3-slugify
| BuildRequires:  python3-requests
| Requires:       python3-pip
| Requires:       python3-six
| BuildRequires:  python3-rpm-generators
| Requires:       python3-rpm-macros

F28 provides python3-slugify 1.2.1, so in addition to syncing the two files above (cf. also bug #1653103 regarding the dependency on requests), either python3-slugify 1.2.6 must be backported to F28 or requirements.txt patched to depend on slugify >= 1.2.1 after checking if tx works with 1.2.1 as well.

Comment 1 Tim Landscheidt 2018-11-29 16:53:29 UTC
I asked upstream what the rationale behind the chosen version numbers in requirements.txt are (https://github.com/transifex/transifex-client/commit/14a1a55c55fe66b1dee1fdfc4f2b1134c3c1af5d#commitcomment-31501220).

I'll post a pull request to fix the issues above, and the scratch-build of it (https://koji.fedoraproject.org/koji/taskinfo?taskID=31179650) functions at least rudimentarily:

| [tim@passepartout ~]$ tx --version
| 0.13.5, py 3.6, x86_64
| [tim@passepartout ~]$

I have not tested whether it does anything useful :-).

Comment 2 Fedora Update System 2018-11-29 18:21:56 UTC
transifex-client-0.13.5-2.fc28 has been submitted as an update to Fedora 28. https://bodhi.fedoraproject.org/updates/FEDORA-2018-240eeb757c

Comment 3 Fedora Update System 2018-11-29 18:22:06 UTC
transifex-client-0.13.5-5.fc29 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2018-cc8d6d811e

Comment 4 Fedora Update System 2018-11-30 03:18:06 UTC
transifex-client-0.13.5-2.fc28 has been pushed to the Fedora 28 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-240eeb757c

Comment 5 Fedora Update System 2018-11-30 15:12:46 UTC
transifex-client-0.13.5-5.fc29 has been pushed to the Fedora 29 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2018-cc8d6d811e

Comment 6 Fedora Update System 2018-12-06 03:56:49 UTC
transifex-client-0.13.5-5.fc29 has been pushed to the Fedora 29 stable repository. If problems still persist, please make note of it in this bug report.

Comment 7 Randy Barlow 2018-12-10 23:19:57 UTC
An update associated with this bug has been pushed to stable.


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