Make colorama dependency optional

[joshuagl]

Fixes N/A

Description of the changes being introduced by the pull request:

• Switch repo script from using colorama directly to using the TERM_ values defined in securesystemslib.interface. These values are set automatically depending on whether colorama is importable, and therefore make the colorama dependency an optional/soft dependency
• Remove colorama from the requirements

Please verify and check that the pull request fulfills the following
requirements:

• The code follows the Code Style Guidelines
• Tests have been added for the bug fix or new feature
• Docs have been added for the bug fix or new feature

[lukpueh]

Sorry for the late comment. But I don't think we actually want to remove coloroma from the requirements files. As (maybe not clearly enough) stated in requirements.txts doc header, the idea is to use requirements.txt to generate a requirements-pinned.txt with all required and optional, immediate and transitive dependencies, to be auto-bumped and auto-tested via Dependabot.

Now, if we remove colorama from these files Dependabot won't notify us about breaking updates.

We use setup.py to encode the minimal set of requirements, which already didn't list coloroma prior to this PR. Also note that the crypto and pynacl extra markers, which indicate optional dependencies, are not in setup.py (but still in the requirements files).

What do you think... @joshuagl, @jku? I'm happy to once more revisit the requirements handling (see #978 and #982 for prior work).

[jku]

so I think you're making a lot of sense (I had missed the idea of generating requirements-pinned.txt completely).

The only thing I'm missing is why do we want colorama as a dependency at all -- as far as I can tell where now using securesystemslib features only, there's essentially no colorama anywhere?

EDIT: or is the idea to document a version for every possible (even transient optional) dependency?

[lukpueh]

so I think you're making a lot of sense (I had missed the idea of generating requirements-pinned.txt completely).

I admit that the documentation is not ideal.

[lukpueh]

EDIT: or is the idea to document a version for every possible (even transient optional) dependency?

I think pip-tools goes one level deep into transitive dependencies. IMO we should at least test securesystemslib, which is basically a part of TUF in a separate package, with all its optional dependencies, because they were added for TUF.

[lukpueh]

If let's say six has an optional dependency that we are not aware of and don't care for, we don't need to test it.

[lukpueh]

That said, I think the easiest thing to do would be to just nuke colorama from securesystemslib. IIRC @trishankatdatadog indicated some regret that it was added in the first place.

[jku]

IMO we should at least test securesystemslib, which is basically a part of TUF in a separate package, with all its optional dependencies, because they were added for TUF.

Fair point, I guess this does make sense. Is this something you'd like fixed before upcoming release?

On the point of nuking colorama completely -- that probably makes sense? there should be a fairly high bar to adding dependencies to projects like this and coloramas usefulness does not seem to reach that bar...

[lukpueh]

Is this something you'd like fixed before upcoming release?

I think there is no fixing needed. Let's just leave this PR merged as is (I did add a note about it to the changelog) and remove colorama in securesystemslib rather soon, hopefully before they push an update that breaks tuf without us noticing, which I think is fairly unlikely.