Proposal to introduce version pinning and license checcking

[b2m]

This pull requests introduces:

• version pinning via pip-tools for reproducible builds.
• license checking via pip-licenses and CircleCI.

New CI features:

• Licenses are checked for new builds (new branch) and when .appoved-licenses or requirements.txt changes.
• The list of allowed licenses is kept in a separate file (.allowed-licenses) to be able to distinguish between changes in CI-Configuration/Tools and license list changes. Also makes transitioning to other tools easier 😁 .

Pipelines showing different settings: https://app.circleci.com/pipelines/github/b2m/dinglehopper?branch=add-pip-licenses

• trigger via change in requirements.txt
• trigger via change in .allowed-licenses
• not triggered by change in .circleci/config.xml

Lessons learned:

• there are no triggers for changed files on CircleCI
• version pinning and license checks need to be performed once per environment as we (could) have environment markers in requirement files
• pip-licenses does not support whitelisting on Python 3.5
• version pinning might get painful to maintain
• we may use some dependency checker like Dependabot to avoid missing security updates because of version pinning.

As we now have a working example we can discuss how to proceed with this requirement in #54.

[mikegerber]

Is the version pinning strictly necessary for this?

[mikegerber]

As for Python 3.5: While poor librarians with ancient Python versions have my sympathies, I think we should just drop support for it as it's EOL for over half a year now.

[b2m]

Is the version pinning strictly necessary for this?

It depends...

Using version pinning we have reproducible builds and are sure that we checked the integrity and the licenses for this combination of libraries and versions. So we freeze this state. As a benefit we only have to run the license check when we have changes in versions or dependencies. (And it is easier to reproduce user reported bugs...)

If we do not use version pinning we just know, that the last time the CI build ran (successfully) everything was OK. But this might change any second when a new version of any library changes that we depend on (directly or indirectly).

So learning the hard way by ignoring version pinning before, my "best practice" perspective is that version pinning in combination with update alerts is absolutely recommendable.

But as with a lot of "best practices" they are not so much fun (might depend on the person =) and require extra efforts.

I was aiming to show a "best practice" example in this pull request and it is OK for me to remove the version pinning if you think it too much for this project.

[mikegerber]

So learning the hard way by ignoring version pinning before, my "best practice" perspective is that version pinning in combination with update alerts is absolutely recommendable.

What was the issue you had to learn the hard way? That would be interesting to know!

While I agree that this pinning is probably the 100% way of doing this, I would rather aim for the much simpler 99% way, also because we have the experience that practically every library has a good license and that python-Levensthein is a rare exception. I also do not expect an incompatible license change to sneak up on us and if it does I think we can detect it with a simple check.

[b2m]

What was the issue you had to learn the hard way? That would be interesting to know!

From the top of my mind here are some instances where not pinning proved to be problematic: (real life events):

• Introducing a new team member and not getting a project to run. Needed a lot of valuable time to find out that it was not MacOS, but a completely different dependency tree.
• Owning failed CI builds because of dependency changes (usually on friday 5pm).
• Having a viral license in some dependency of a dependency of a completely unnecessary dependency.
• Having to ask users to provide extensive enrionment information to reproduce simple bugs.
• Spending tooooo much time trying to sync my environment with the CI environment to be able to run failed tests.
• Libraries completely unusuable and uninstallable because of breaking changes in used dependencies.
• missing important security updates

And here are the problems I remember from using version pinning:

• missing important security updates
• version conflicts when using multiple libraries that use version pining