Removes top level requirements.*

[kurtwheeler]

This will resolve: #17

These two files are not actually required by anything in this project. In the past I think there were some dependencies which were needed for the whole project but all of these got moved into the Docker containers for different sub-projects. The only python package needed by the entire repo is pip-tools, but the install.sh script installs that into a virtualenv for the user, so it doesn't seem necessary to have a requirements.txt with only that one line in it.

[mhuyck]

This seems like a good cleanup to me. Just two things to make sure you've thought about:

(1) I assume pep8 and flake8 are things you'd want for development still, but maybe you don't need them integrated in to the source repo. Do you have another way to automate running these tools?

(2) One potential flaw with installing pip-tools via shell script the way you have is that you no longer control for the release version. This could conceivably make reproducibility hard. Have you considered this angle?

[kurtwheeler]

Re:

Do you have another way to automate running these tools?
I'm not entirely sure what you mean there. I have them installed on my machine, but I guess I don't have a way to install easily other than running the commands to install them (optionally into a virtualenv).

Re:

This could conceivably make reproducibility hard.
I don't think that will be an issue because the only thing pip-tools is used for is to compile requirements.ins into requirements.txts. Since both of these files are under source control I don't see how reproducible would be hard, since all the requirements.txt files specify the exact version for everything that is actually installed into a Docker container.

[mhuyck]

Re: pep8 and flake8:

Sorry, I sorta conflated the step of installing these tools with how they are used. To elaborate: we don't have pep8 or flake8 in our repo for adage-server either, so it makes sense to me to remove them here. Each of us still uses them (or a similar linter) to check code, though. I have a trigger in my editor to run them for Python files. We also rely on codeclimate integration through GitHub to perform those checks and more.

[mhuyck]

Re: pip-tools:

Good point. Tracking the specific version of that tool does not matter as much as what it's actually installing. Mostly I just wanted to make sure you had considered the implications of that. It also occurs to me that you'll have reproducibility somewhat covered by the Docker repository as well, right? If you needed to get back to a specific container state you should be able to dive into the history of the images you've pushed.