Version Pinning for "Operational" *master* Branch

[egyptiankarim]

Given the recent trouble with our dependencies drifting in and out of compatability, I'm proposing we version pin master to a conservative, known-to-be-working set. I took a naive approach here and just == the latest versions of various components that I knew worked for my personal usage. There may be a more pythonic way of doing this, but I'm not super familiar with the idioms.

[IanLee1521]

This looks good to me.

I think this is the other good reason to have requirements.txt vs defining dependencies in your setup.py file that I wasn't thinking about on #139

[jsf9k]

Might this complicate installation alongside other pip packages, though, if we're requiring specific versions. I can envision a situation where

• pshtt would work with version 1.2.3 of somepackage, but we have nailed down the version to 1.2.2 in setup.py because we didn't notice that there had been an update to somepackage in PyPI.
• Now pshtt can't be installed alongside yetanotherpackage that depends on version 1.2.3 of somepackage, even though that would work just fine.

I'm afraid that nailing down the versions will require us to continually tweak the versions to allow pshtt to play well with others.

[egyptiankarim]

Might this complicate installation alongside other pip packages, though, if we're requiring specific versions.

That's a super fair point that I hadn't considered. I'm very Docker-centric, and I wasn't thinking of potential package management issues outside of containers. Does Python have anything akin to Ruby's Bundler? I'm so used to having tight, project-level control over these types of things.

[jsf9k]

I'm of the opinion that we should not merge this. Instead we should just let #146 get merged into master the next time we do a PyPI release. I think this may break a lot of interoperability with other packages and it be a headache to maintain.

I could be convinced otherwise, though.

[konklone]

I've definitely experienced more issues with pshtt's requirements being too locked-down (where the point versions fall out of date from upstream dependencies), than I have issues with it being too flexible. But in general, I am not using a Docker-based workflow, and am generally just relying on pip install in a persistent Linux environment. (More recently, I am building environments for Lambda functions, the build process for which also involves using pip, but it doesn't resemble either persistent or Docker-based environments.)

#146 also looks more promising, but I do think that for this project to hit its greatest potential, it should have solid Docker and non-Docker stories. I wonder if this actually points to a synchronous video meeting or something to work out a reasonable path.

[konklone]

I'm of the opinion that we should not merge this. Instead we should just let #146 get merged into master the next time we do a PyPI release. I think this may break a lot of interoperability with other packages and it be a headache to maintain.

Closing in favor of resolving #146 one way or the other.