Remove usage of tee to avoid read-only issues on Windows

[djhoese]

Closes #427

This follows the suggestions by @mwcraig to remove the usage of tee from setup_dependencies_common.sh. I still don't understand why Windows is making the file descriptor read-only for the pipe or what's going on and I'm still worried about this triggering CI time outs from no conda output, but if this makes "best case" Windows builds pass then so be it.

I'll be testing this with my own project and I'll report back later.

[djhoese]

My stuff is still failing (at least setup isn't complaining about a read-only file system): https://travis-ci.org/ssec/sift/jobs/613285808

This looks like it is happening before my project-specific packages are being installed (I think).

[bsipocz]

Hmm, weird. What happens if you switch to pip install everything?

[bsipocz]

(also, that being the case, I've cancelled CI here for now. Happy to restart if you prefer)

[djhoese]

I've made another branch remove-tee2 on my fork where I just removed all of the retry stuff just to see what's really going on (raw conda command). I'm going to go offline in a bit and will test some more stuff tomorrow. I should see if I can get my hands on a Windows machine at work tomorrow and try some of these conda install commands just to see how it resolves the dependencies.

[djhoese]

@bsipocz I'm still investigating. Any idea why travis on Windows would not be echoing the output of commands in the setup_dependencies_common.sh to the travis "console"? Even commands line cat $PIN_FILE aren't printing anything. I suppose the file could be empty, but even conda install commands don't show anything. It has output from the set -x output but not much else.

https://travis-ci.org/ssec/sift/jobs/613295668

[djhoese]

Ok so I did a lot of playing around on a Windows VM and found out that I'm running in to this issue: conda-forge/scipy-feedstock#120

I'll try removing strict channel priority for my own project to verify that something better happens, but bottom line is that conda basically thinks the environment is unsolvable. @bsipocz I think you could start up the tests again.

You/we may want to document that hitting the 10m timeout on travis or other CIs is likely caused by an unsolvable environment that conda is trying its hardest to solve. If you need me to add that somewhere point me to where you think is best and I'll give it a shot.

[djhoese]

My project passes. I had to make the Windows build flexible channel priority: https://travis-ci.org/ssec/sift/builds/613681043?utm_source=github_status&utm_medium=notification

[bsipocz]

OK, so your project passes, this passes, I'm going ahead and merge it then.

Thank you @djhoese!