Support #20875
openDeprecate OS packages for client tools
Description
Make a note in upgrading notes that OS packages for client tools (described in #20838) will be discontinued in favor of PyPi / Rubygems / binary distribution (for Go tools) only.
Updated by Peter Amstutz over 1 year ago
- Subject changed from Deprecate OS packages for client tools to Deprecate OS packages of client tools in favor of pypi/rubygems only
Updated by Peter Amstutz over 1 year ago
- Blocks Support #20838: Discontinue OS packages of client tools in favor of pypi/rubygems only added
Updated by Peter Amstutz over 1 year ago
- Description updated (diff)
- Subject changed from Deprecate OS packages of client tools in favor of pypi/rubygems only to Deprecate OS packages for client tools
- Tracker changed from Idea to Support
Updated by Peter Amstutz over 1 year ago
- Status changed from New to In Progress
Brett: we should see if binary wheels exist for pyCURL and llfuse that are statically linked and can run without needed the user to install OS packages like libcurl and libfuse.
Updated by Brett Smith over 1 year ago
Peter Amstutz wrote in #note-4:
Brett: we should see if binary wheels exist for pyCURL and llfuse that are statically linked and can run without needed the user to install OS packages like libcurl and libfuse.
As far as I can tell neither project publishes prebuilt wheels, at least for Debian 11. Testing process:
$ podman pull docker.io/library/debian:11-slim
$ podman run -ti debian:11-slim
# apt-get install python3-pip python3-venv
# python3 -m venv /opt/arvados
# /opt/arvados/bin/pip install wheel
# /opt/arvados/bin/pip install 'arvados_fuse==2.6.3'
(after that failed:)
# /opt/arvados/bin/pip install 'arvados-python-client==2.6.3'
In both cases pip ended up downloading source for various versions, and they both failed looking for curl-config
and pkg-config
respectively.
Updated by Peter Amstutz over 1 year ago
Instead of completely deprecating and removing OS packages, maybe what we should do is have a Python version support policy and if an OS doesn't provide a new enough Python, we just don't publish Python packages. In which case the only code change we need to make is to be able to ignore building and publishing Python packages for specific distros.
Updated by Peter Amstutz over 1 year ago
- Related to Support #20893: Investigate using PyInstaller to build self-contained packages added
Updated by Peter Amstutz over 1 year ago
Tom had a great idea, we could use PyInstaller to make self-contained packages for OS versions where the native Python is too old, see #20893
Updated by Peter Amstutz over 1 year ago
- Target version changed from Development 2023-08-30 to Future
- Status changed from In Progress to Feedback