Repository: pyro-ppl/pyro

Issue:
Have Pyro dev branch track PyTorch's master branch
For the foreseeable future (until distributions are migrated), we would like travis CI to build off of PyTorch master, rather than the release branch. 

Steps for a potential strategy:
 - [ ] Use travis cache to cache the packages installed via pip.
 - [ ] Build PyTorch's master branch in travis and cache this build to be used for all later travis builds.

Edit - the strategy above did not work for multiple reasons - travis's cache is partitioned by environment keys (bloats the number of binaries stored), suffers from potential cache corruption issues, does not play well with staged builds, takes too long to build PyTorch etc. In the end, we decided to build the binaries separately and upload them to S3.


Discussion:

Resolving patch:
diff --git a/examples/dmm/dmm.py b/examples/dmm/dmm.py
--- a/examples/dmm/dmm.py
+++ b/examples/dmm/dmm.py
@@ -222,8 +222,7 @@ def guide(self, mini_batch, mini_batch_reversed, mini_batch_mask,
 
         # if on gpu we need the fully broadcast view of the rnn initial state
         # to be in contiguous gpu memory
-        h_0_contig = self.h_0 if not self.use_cuda \
-            else self.h_0.expand(1, mini_batch.size(0), self.rnn.hidden_size).contiguous()
+        h_0_contig = self.h_0.expand(1, mini_batch.size(0), self.rnn.hidden_size).contiguous()
         # push the observed x's through the rnn;
         # rnn_output contains the hidden state at each time step
         rnn_output, _ = self.rnn(mini_batch_reversed, h_0_contig)


Test patch:
diff --git a/tests/README.md b/tests/README.md
new file mode 100644
--- /dev/null
+++ b/tests/README.md
@@ -0,0 +1,38 @@
+# Testing
+
+### Building PyTorch binaries for Travis CI
+
+The Pyro development on `dev` branch may use the latest features that are not present in the 
+release version of PyTorch. As such, these features need to be tested against PyTorch's master 
+branch rather than the release branch, which may be a few months older.
+
+For this, we need to build PyTorch binaries on a need-be basis, and upload them to an S3 bucket, 
+from which these binaries can be pulled in by CI machines to build Pyro's `dev` branch. Note that 
+to build small sized binaries, we remove all CUDA dependencies, but have statically linked MKL
+libraries which are not present on CI machines otherwise. 
+
+We use the scripts in the [PyTorch builder](https://github.com/pytorch/builder) repo for this. 
+In particular, use the following instructions for building the binaries:
+ - Clone the [PyTorch builder](https://github.com/pytorch/builder) repo on your local system.
+ - Under the `manywheel` directory, run a docker container:
+     ```sh
+     cd manywheel
+     docker run -it --ipc=host --rm -v $(pwd):/remote soumith/manylinux-cuda80:latest bash
+     ```
+ - Modify the `build_cpu.sh` script as follows:
+   - Remove all environment variables declared in the beginning of the script, except for 
+     `NO_CUDA` and `CMAKE_LIBRARY_PATH`.
+   - Instead of checking out the version tag through `git checkout tags/v${PYTORCH_BUILD_VERSION}`, 
+     check out the commit/branch you would like to build.
+ - We need to update `cmake` to version 3 to build PyTorch master:
+     ```sh
+     yum install epel-release
+     yum install cmake3
+     yum remove cmake 
+     ln -s /usr/bin/cmake3 /usr/bin/cmake
+     ```
+ - Then run, `./build_cpu.sh` under the `remote` folder, which will create the required binaries 
+ in `/wheelhouse` directory.
+ - Upload the binaries for python 2.7 (`torch*cp27mu*.whl`) and python 3.5 (`torch*cp35m*.whl`) 
+   to the S3 bucket `s3://pyro-ppl/ci` with public read permissions.
+ 
\ No newline at end of file