Installation via conda raises ResolvePackageNotFound on Windows. Two conda channels missing for a fix.

[remtav]

On Windows (10), conda can't find torchvision nor pycocotools:

(base) C:\Users\...>conda env create -f environment.yml
Collecting package metadata (repodata.json): done
Solving environment: failed

ResolvePackageNotFound:
  - torchvision[version='>=0.10']
  - pycocotools

Adding pytorch and esri in channels of environment.yml seems to fix this issue.

[adamjstewart]

Yes, the PyTorch recipe for conda-forge does not support Windows. Note that it can be dangerous to mix channels because conda does not ensure ABI compatibility, and conda-forge explicitly recommends against mixing channels. For this reason, our environment.yml only uses conda-forge and not any other channels.

My personal suggestion would be to avoid using conda or to avoid using Windows. Spack has superior ABI compatibility because it builds everything from source, although Windows support is still experimental. On Windows, you can install Linux via WSL and do things in Linux instead. Pip has also gotten surprisingly good now that most packages have wheels, although fiona/rasterio still don't have Windows wheels and require conda to install.

Hope this helps! Sorry I don't have a better answer.

[weiji14]

Related issues: conda-forge/torchvision-feedstock#23 and conda-forge/pycocotools-feedstock#16. Might pay to see if we can push on those issues/PRs to get resolved in conda-forge directly.

[remtav]

oups just opened a PR before seing your reponse @adamjstewart. I'll close and resolve on my side. I thought this could be useful for other windows users (and without consequence for linux users). I'll look into WSL and Spack.

I've been mixing conda channels for a while and never had trouble. Maybe mixing conda-forge with the defaults channel (as is mentionned in the referenced link) causes more problems than other mixes. If the good practice is explicitely defined for not using multiple channels, then be it. However, I can hardly see how one can use a single channel for all purposes. For example, Pytorch points to its "pytorch" conda channel for installation of pytorch, torchvision, etc.

[isaaccorley]

+1 for WSL. It's gotten better over time and VSCode has a nice Remote WSL extension. It also supports access to CUDA devices directly now so you can train on your GPU.

[adamjstewart]

I've been mixing conda channels for a while and never had trouble. Maybe mixing conda-forge with the defaults channel (as is mentionned in the referenced link) causes more problems than other mixes.

That could very well be the case. If someone can confirm that #528 doesn't cause issues on macOS or Linux then I would be fine with merging that kind of solution. I just get the impression that if you run into any kind of issues like that, the first thing the developers will say is to avoid mixing channels.

[remtav]

@adamjstewart I can confirm the conda environment creation from #528 works on Ubuntu 20.04. It does raise a "pip subprocess error" but that's also the case with current environment.yml:

Pip subprocess error:
  Running command git clone --filter=blob:none --quiet https://github.com/pytorch/pytorch_sphinx_theme /tmp/pip-req-build-g89ucqfc
ERROR: Could not find a version that satisfies the requirement open3d>=0.11.2 (from versions: none)
ERROR: No matching distribution found for open3d>=0.11.2

failed

CondaEnvException: Pip failed

Commands from installation instructions succeed however:

conda activate torchgeo
pip install .

To solve this open3d error, moving the open3d dependency to the conda section of environment.yml rather than pip and adding the "open3d-admin" channel does it. This also implies one more conda channels. I can open a separate issue and PR if necessary.

EDIT: I'm down the rabbit hole. Conda installation on Ubuntu 20.04 also installs a cpu version of pytorch and torchvision. In my project, the only remedy I've found was to hardcode the pytorch package to use. Poor solution.

[adamjstewart]

Yeah, that's another complaint I have with conda, there's no way to expression "optional" dependencies. Open3D isn't necessary for 99% of users but we have no way to express that. If adding an extra channel solves the issue then that could be a good solution. Want to reopen #528 and add that?