Actions
Issue #5696
closed
dependency pinning makes packaging pulp3 more complicated than necessary
Start date:
Due date:
Estimated time:
Severity:
3. High
Version:
Platform Release:
OS:
Triaged:
Yes
Groomed:
No
Sprint Candidate:
No
Tags:
Sprint:
Sprint 61
Quarter:
Description
pulpcore (today) defines the following requirements:
requirements = [
'aiohttp',
'aiofiles',
'backoff',
'coreapi~=2.3.3',
'Django~=2.2.3', # LTS version, switch only if we have a compelling reason to
'django-filter~=2.2.0',
'djangorestframework~=3.10.2',
'djangorestframework-queryfields~=1.0.0',
'drf-nested-routers~=0.91.0',
'drf-yasg~=1.17.0',
'gunicorn~=19.9.0',
'psycopg2-binary',
'PyYAML~=5.1.1',
'rq~=1.1.0',
'redis~=3.1.0',
'setuptools>=41.0.1,<41.7.0',
'dynaconf>=2.2,<2.3',
'whitenoise~=4.1.3',
]
I understand that the idea behind this is to ensure that it can only be ever installed with tested dependencies (see https://pulp.plan.io/issues/5196 for the original discussion and decision).
However, this raises the following "issues" when deploying pulpcore via (RPM) packages:
- psycopg2-binary is not meant for production setups and people shall use psycopg2, because the binary package is a practical choice for development and testing but in production it is advised to use the package built from sources.
- setuptools is usually already provided by the OS, but often an older version (albeit one that should still work fine for the pkg_resources calls that pulpcore does).
As pulpcore uses pkg_resources.get_distribution at runtime, it will error out when psycopg2-binary or a sufficiently new version of setuptools is not found and Pulp won't work.
While I can easily patch both things during package building, I think this warrants a broader discussion how production grade setups shall be handled.
Actions
.
Fixing package requirements for CentOS 7
Also bump gunicorn version requirement.
fixes #5696