Check for new versions of wheels in PyPI

[natefoo]

Add the wheel_updates command to list wheels with newer versions on PyPI. Introduce the pinned attribute on packages in wheels.yml to exclude them from this check.

TODO: just realized rather than a "yes/no" pinned state, we may need to support standard pkg_resources version specifiers, e.g. we should get additional patches to mercurial 3.4 but not upgrade to >= 3.5. So mercurial should be "pinned" to <= 3.5

[natefoo]

Added the version_specifier attribute to wheels.yml to allow for pinning for patch updates.

[jmchilton]

I suggest a new plan - less infrastructure - more standard Python. How about this... we use Pipenv (ala galaxyproject/galaxy#4876) to manage dependencies in dev (sticking with it just as a tool for generating requirements.txt for now) and we sort of say we expect to get dev dependencies from PyPI to move fast in dev. We still use a pinned (and now hashed also) requirements.txt file but once a week we open a PR that updates the locked files with the latest and greatest and run tests and such. Then starforge would kick in at release time, once we have our release dependencies locked down you could write a script that would just grab those and update starforge and deploy the dependencies. This allows us to move fast in development and be very targeted about what we use for releases.

[natefoo]

+1. One additional step though, once Starforge builds all the dependencies, Galaxy should be tested with those.

[jmchilton]

Once you open a PR with new hashes the tests should run. Figuring the hashes out may be tough.

[natefoo]

Starforge already outputs the hashes of built wheels. Or are you referring to something different?

[jmchilton]

I just meant figuring out how to combine the starforge and PyPI hashes in the requirements file for Galaxy. But it sounds like we are moving this from starforge to cargoport so this probably won't be such a problem - this whole issue seems moot now.

[natefoo]

Superceded by pipfile/pipenv.