Installing Python package clobbers installed Pytorch

[cynthia]

As I understand the build process, it seems like the Python bindings do not necessarily have to depend on Pytorch, as it's used only for building the resources.

At the moment installing through setup.py clobbers the current environment's installed Pytorch to 0.4.1, which seems like a dealbreaker for anyone who wants to use this package as part of their analytics pipeline, who also uses Pytorch. (which, most likely is going to be a more recent version)

It feels like there are two ways forward for this:

1. Only require Pytorch for the build process, remove dependency from bindings and possibly make the resource builder another package that does depend on it. (this would allow users to split environments, which is suboptimal but worse than overwriting the installed version)
2. Respect and try to make use of whatever Pytorch version the user has.

2 seems like a bumpy road forward considering the stability of the API. Another option would be to have pre-built models as downloadable static resources so users don't have to deal with the resource building process - it does feel like something only seasoned users would be interested in.

[krikit]

Thanks for your good proposal. Actually the model parameters are not necessary to be compiled every time. We will consider removing PyTorch dependency from dictionary compile process.

[cynthia]

I think having the pre-trained models downloadable as static resources somewhere would be ideal, a lot of frameworks do this by sticking datasets and pretrained models on say S3. Since there is a cost factor here, I'm curious if you can put it on say, http://mirror.kakao.com as an alternative solution.

(The one downside is that that site doesn't seem to support H2 or TLS, so it could be considered rather insecure.)