Unpin versions in setup.py (2nd attempt)

[ldionne]

This patch unpins versions in setup.py since they are pinned in requirements.txt. This is effectively a revert of 11c2d9e and 8fc27f4.

When we originally unpinned versions from setup.py, some clients were running setup.py directly to install lnt, which means they started fetching untested and incompatible versions of packages.

Since then, we've documented the new installation procedure based on pip and our pinned requirements (in #70).

[ldionne]

(We should wait for #70 to land and for clients to be updated to use the pip installation instructions before landing)

[fhahn]

Does this still leave python setup.py develop broken?

I don't think this should broken by default. If there's no way to make this work, can we just remove them alltogether?

[ldionne]

Does this still leave python setup.py develop broken?

I don't think this should broken by default. If there's no way to make this work, can we just remove them alltogether?

Well, it's not "broken" in the sense that python setup.py will install the module with the version of the dependencies specified in setup.py unversioned, which is the intent. However, that will result in a broken installation in 99.9% of the cases since you won't have appropriate versions of the dependencies.

As we update our dependencies to ones that aren't 10 years old and unsupported, python setup.py could very well start working again since the latest version of our dependencies should be usable. Right now the issue is that we have to pin ancient versions for anything to work.

Eventually, we can move away from setup.py and replace it by pyproject.toml which is the current best practice, but that should be done separately.