intelmq icon indicating copy to clipboard operation
intelmq copied to clipboard

RFD remove, integrate or replace termstyle package

Open bernhardreiter opened this issue 9 years ago • 10 comments

Right now it seems that intelmq depends on https://pypi.python.org/pypi/termstyle/0.1.10 which is considered "dormant" from the author.

Because terminal styling may not be the most important task, I think we may ease our packaging by going to a more stable situation here. Either:

  • remove termstyle entirely (did so for https://github.com/Intevation/intelmq-mailgen/issues/11 )
  • integrate and ship it as part of intelmq (thus be prepared to maintain it ourselfs or occasionally sync from https://github.com/timbertson/termstyle/
  • switch to a different library. More popular and actively maintained seem to be, for example
    • https://pypi.python.org/pypi/termcolor
    • https://pypi.python.org/pypi/blessings

bernhardreiter avatar Jun 01 '16 20:06 bernhardreiter

which is considered "dormant" from the author.

All the module does is inserting ANSI escape codes, there's not much to maintain.

Packaging is not hard, it's just a plain python package. Did it for opensuse recently, no pain at all.

But as it's not used in your case anyway, you may want to first evaluate what you need. Then decide what to use.

sebix avatar Jun 01 '16 20:06 sebix

This is a small cleanup issue, of course. I know that termstyle is simple and small, but it is also somehow unmaintained. There is a small extra hurdle that may bite us later (in a few years of maintenance) and now if someone wants to get started soon.

Yesterday I ran into this, I wanted to start intelmq-mailgen (which then still used termstyle) on Opensuse 13.1. No termstyle packaged there. Once I've looked at the file, I knew that packaging is not the main issue, I could have just placed the file there, however I would have had to think which is suboptimal. If a person that want to install intelmq needs to do this for many small packages it adds up fast.

bernhardreiter avatar Jun 02 '16 07:06 bernhardreiter

Yesterday I ran into this, I wanted to start intelmq-mailgen (which then still used termstyle) on Opensuse 13.1. No termstyle packaged there. Once I've looked at the file, I knew that packaging is not the main issue, I could have just placed the file there, however I would have had to think which is suboptimal. If a person that want to install intelmq needs to do this for many small packages it adds up fast.

Working on it. I plan to push it to other suse's also. It's already in tumbleweed and leap 42.2.

sebix avatar Jun 02 '16 11:06 sebix

@sebix: If you think that termstyle (which only works on some platforms I assume) is an improvement to the Free Software world (over all the other python packages for terminal colors out there).... it is very cool that you are stepping up at its maintainer. :)

But again: it is a small cleanup issue and with or without better packaging, it poses a hurdle for new intelmq "admins" now.

(Just trying to make my point clearer. Of course it is up to you to decide what is best and there is no urgent need to act fast because it is just a small issue.)

bernhardreiter avatar Jun 03 '16 08:06 bernhardreiter

termcolor is packaged more often than blessings. (looking at debian, ubunu, suse, fedora)

Concerning dropping: I'd like to color the log output for intelmqctl, having errors in red etc. Would that sound like a good usecase for you?

sebix avatar Sep 15 '16 18:09 sebix

Regarding dropping: If you like colors in such an interactive command, that's fine to have it. :)

As far as I read, termcolor and termstyle may not be fully cross plattform and termcolor is widespread, but does not seem to very active (last release 2011). (Sooner or later there will be a defect or a missing option.) Anyway I'm fine with everything, that lower the installation barrier and has potential for the future.

bernhardreiter avatar Sep 16 '16 06:09 bernhardreiter

Regarding dropping: If you like colors in such an interactive command, that's fine to have it. :)

I think it enhances the user experience if you are able to glance errors and warnings quickly, journalctl has them too.

As far as I read, termcolor and termstyle may not be fully cross plattform

Also platforms, which relevant to us?

Packaging blessings isn't a problem too, it's just a python package.

sebix avatar Sep 16 '16 06:09 sebix

Re: Platforms: I've read that Windows is not supported by termcolor, I don't know if windows is a relevant platform for intelmq.

There is also https://github.com/broadinstitute/xtermcolor I believe anything is better than termstyle (because of the dormant state). So pick whatever you like, is more widely packaged or is easiest.

bernhardreiter avatar Sep 16 '16 07:09 bernhardreiter

There is a further wrinkle concerning this, which is that while the RPM packages depend on termstyle:

# rpm -q --requires python3-intelmq | grep dist.*termstyle
python3.8dist(termstyle) >= 0.1.10

setup.py says it depends on python-termstyle: https://github.com/certtools/intelmq/blob/7ebb8e16d821c372a44b077dd18a151c07f75807/setup.py#L18

termstyle and python-termstyle are similar enough that the API is the same (as is their homepages and documentation on PyPI), so the code runs, but different enough that pip treats them as different packages.

This became a problem for me when I wanted to run my local copy of IntelMQ, installed through pip, to get my own bots, but have the Manager installed through RPM packages to avoid having to deal with it. I installed intelmq and intelmq-manager from RPM, which among others pulled in termstyle as an RPM, and then uninstalled the python3-intelmq RPM while leaving its dependencies intact. When I then tried to install my local copy of IntelMQ, pip refused to do so since it couldn't find python-termstyle:

ERROR: Could not find a version that satisfies the requirement python-termstyle>=0.1.10 (from intelmq==3.0.2) (from versions: none)
ERROR: No matching distribution found for python-termstyle>=0.1.10 (from intelmq==3.0.2)

Since @sebix already packages termstyle as RPM, I'd suggest changing setup.py to also depend on that when using pip.

creideiki avatar Nov 22 '21 12:11 creideiki

Good point, I wonder why this didn't cause problems earlier

sebix avatar Nov 22 '21 19:11 sebix