Improving the way we manage requirements

[eduardogr]

What are you going to find?

• Now all versions are pinned, no >= or > without an upper bound is used
• Extracting dev requirements into a new file
• Extracting cubit requirements into a new file
• Moving requirements file to a new directory 'requirements'
• New Makefile provided for development commands
  • creating a virtual env
  • removing packages from within the virtualenv
  • installing bittensor, bittensor[dev], bittensor[cubit]

Why pinned versions?

We should know the quality of what we release so we need to know if the released version works or not.
If we let dependencies open and some update breaks the version, we are going to end up with a bittensor broken scenario. Potentially miners are going to have a different set of packages<=>version and we do not want that, we want to know as much as possible about what people is running.

What about updating packages?

Within the proposal of this change, packages updates will be related with a bittensor new version release and, of course, a dedicated branch and time to check if the new package version integrated is working along our basecode.

What i need form you reviewing this PR?

I need a double check that the pinned versions are the ones we want.

Thanks!

New ways to install bittensor in a development environment

Installing bittensor for a development environment

python3 -m pip install '.[dev]'

Installing bittensor with cubit

python3 -m pip install '.[cubit]'

[Eugene-hu]

LGTM, but the testing change might have showcased some new flaky tests. We should fix them asap.

[camfairchild]

Looks good to me