Closed drasmuss closed 5 years ago
The second solution seems better to me:
tf-nightly*
packages will likely have the expertise to do pip install nengo-dl --no-deps
and then install the other requirements manually (are there other requirements?)Actually it looks like the TF1.14 dynamic GPU support doesn't work on windows (see the failing appveyor build). So I'll go with the first, hacky fix for now, with the hope that in the near-ish future we can switch to something like the second fix once that is fully supported in TensorFlow.
Adding a
pyproject.toml
switched us over into pep517-style pip installation, which means thatsetup.py
gets executed within an isolated build environment. This makes it difficult to check whether or nottensorflow
is installed, which breaks our conditional logic insetup.py
which would attempt to look for a pre-existingtensorflow-gpu
installation. This means that oursetup.py
was installingtensorflow
overtop of an existingtensorflow-gpu
installation, which breaks the GPU support.There are two fixes here. The first is a kind of hacky fix that attempts to find the original (non-isolated)
site-packages
directory and then look in there fortensorflow-gpu
. It's hacky, but it preserves all the same functionality as before.The second fix takes advantage of a change in the most recent version of TensorFlow (1.14), which allows the
tensorflow-gpu
package to be used whether or not GPU support is actually available (if it isn't available, you just end up with CPU-only tensorflow). So we can just requiretensorflow-gpu>=1.14
in all cases, and it will always work. This has the advantage of simplicity, but it is a slight downgrade from a user experience. 1) It won't play nicely withtf-nightly*
packages, 2) it will forcetensorflow-gpu
to be installed even if the user has an existingtensorflow
(non-gpu) installation.