Create install package(s) for CentOS

[ampledata]

spotcot, et al, are extensively tested on Debian derivative operating systems, but very little testing happens on CentOS. For the most part, whenever we've tried to run spotcot on CentOS it works, but does require several additional operating system packages.

For this issue, we'd like to create a CentOS installable (yum/rpm) package that also installs all additional requirements. The end result should be a 'spotcot' command-line command that any user can run without error. At a minimum it should return help '-h'.

[ampledata]

There's a bounty for this: https://www.bountysource.com/issues/96736337-create-install-package-s-for-centos

[Chocobo1]

Hi, I'm interested in solving this.

Currently I already have a working .spec file that will create the spotcot package. However I'm facing some problems with the dependencies: not every dependency (e.g. pycot, pytak) is readily to download from the CentOS package repo. How should we solve this? I can think of a few ways:

1. Create a .spec file for each of the dependency (and all dependencies it brings in). Pros: This would be ideal from a user perspective as everything is tracked by the package manager. Cons: Unless you have access and able to upload the packages to epel (CentOS/fedora package repo by community), users would still need to install these packages manually (or with a script) and you would need to maintain the .spec files and build them.
2. Let users install the dependencies from pypi, that is using pip3 install --user Pros: We don't have to deal with multiple .spec files Cons: Could be messy for the users if they mess with the python packages.

What do you think? Note that none of the above solutions would make the installation as easy as installing a single package...

[italic-r]

The issue I've been finding this week is that all the dependencies for spotcot need their own RPMs, but not just pytak, pycot and aiohttp; most of aiohttp's deps also need to be packaged, and they're a messy spaghetti of version locks.

This may sound backwards, but I would love a single RPM with a post-install script to create and populate a venv, while a (pre-)uninstall script removes the venv and the spotcot entrypoint is actually a script to activate the venv and run the binary. This way it would follow PyPI's version of spotcot while autopopulating all dependencies. This sounds very hacky, though.

I think a better way would be to distribute an install script that takes input for a custom venv (new or preexisting), installs a startup script to target that venv somewhere in $PATH, possibly gives an option to upgrade an existing installation, etc.

What I've gleaned for unavailable packages (and version requirements):

• Python36 (epel version-locked, later versions in scl available)
• pycot
  • gexml >=1.0.0
• pytak
  • asyncio_dgram unversioned
• aiohttp is locked to <=3.7.4 (4.x requires py 3.7+)
  • multidict >=2.0, <7.0
  • async_timeout >=3.0, <4.0
  • yarl >=1.0, <2.0
  • idna-ssl >=1.0
  • typing_extensions >=3.6.5

These all require being built and packaged. I haven't explored deeper deps than direct deps of aiohttp, but I don't doubt we'd need to package a few more.

To be clear, I can successfully pip install spotcot; spotcot -h in a venv without issue, so whatever needs to get pulled down gets pulled.

One last point, I've been able to build RPMs with python setup.py bdist --formats=rpm, but that doesn't put proper RPM deps into the .spec, ie installing spotcot.rpm does not require aiohttp.rpm to complete installation; it would result in a broken installation. Official documentation says the builder can use a bdist argument like --requires= to populate that field in the spec, but I have not explored that yet.

[Chocobo1]

OK, I've been testing another idea, that is leveraging pip install and let it install the dependencies to /usr/lib/spotcot, this is done at package install time (contrary to rpm packaging time). The main entry point /usr/bin/spotcot is actually a shell script that would tell python to find the dependencies/modules under that path.

Here is the result package: spotcot-2.0.2-1.el8.noarch.zip ps. Tested in CentOS8 4.18.0-240.15.1.el8_3.x86_64 pps. Due to limitations of github, the package is zip compressed. Unzip it first and install it with sudo dnf install ./spotcot-2.0.2-1.el8.noarch.rpm ppps. Reupload a few times to fix some minor issues

If it works well for you, I can submit a PR anytime.

[ampledata]

I appreciate everyone's work on getting spotcot packaged. The solution for the end-users I'm expecting to use this is to have everything available via RPM, albeit as individual RPMs, not a single all encompassing RPM. I don't think these users will be able to use Github, nor will they be able to handle the complexities of installing python packages individually.

I'll open a matching issue for the top level projects and match the bounty there, and we can work back to this one.

[srevinsaju]

I would like to suggest a platform independent mode of distribution, which will help reduce the cost of maintaining it in the future. This will also benefit a lot of other linux distributions other than CentOS / Fedora too. As long as the dependencies are not on CentOS distribution, I would suggest using AppImages as the mode of distribution. AppImage's are probably the most intuitive solution for end users. If you are interested, I can introduce a Continuous Integration and Build system on GitHub Actions to automatically build AppImages, and release them to releases, on every commit, or on every tag, depending upon your preference. Overall, this system would be very maintainable, because most of the stuff becomes automated + this new package not only supports just "centOS", but will work on almost all popular linux distributions.

Shall I proceed with this and create a Pull request for the same?

[riteshja88]

Please check https://github.com/riteshja88/spotcot/blob/pip_riteshja88/README.md

[riteshja88]

@ampledata can you please take a look at my submission?

pip is the defacto standard for python package management, i think its best to host spotcot as a pip package(platform independent) instead of a rpm(platform dependent).

[riteshja88]

@ampledata request you to check and if this addresses your purpose, request to close this PR, so that the bounty can be claimed.

[riteshja88]

@ampledata gentle reminder

[ampledata]

@riteshja88 I appreciate the effort, but this project is already up on pypi and is installable via pip. I agree that using pip is the preferred method, but I do have a need for an RPM package for some of my uses-cases.