older versions of pytorch3d

[scott-vsi]

Install.md says there are prebuilt wheels, and you provide a command to install from within iPython or a notebook. However, this command doesn't work for very many combinations of environments. In fact, currently, I can find only 3 links that exists (for python 3.7, 3.8 and 3.9 for PyTorch 1.9 and CUDA 10.2). It would be nice to have that list somewhere so it was easier to figure out how I need to modify my environment to install a pytorch3d wheel (I am not using conda).

Also, is there a reason you don't continue to host older versions of pytorch3d? You could host these in the same way that PyTorch does, using links that look like

pip install torch==1.6.0+cu101 -f https://download.pytorch.org/whl/torch_stable.html

[bottler]

These wheels were mainly created for colab users. Before the latest release, I changed the build to only make these wheels for versions of dependencies (Python, PyTorch and CUDA) equal to those included in colab or newer. The code is here. The current Python is 3.7, the current PyTorch is 1.9.0, and the current CUDA is 10.2. PyTorch 1.9 only has builds for CUDA 10.2 and 11.1. So the current builds are:

[Python 3.7 or 3.8 or 3.9] x [PyTorch 1.9.0] x [CUDA 10.2 or 11.1]

I deleted the old builds on release because I was worried about people silently installing an old version on requesting a combination of dependencies which used to be supported but no longer is.

I can easily add some more builds for the current release, especially if you or others have particular versions of dependencies which you care about.

[scott-vsi]

Thanks for the info! I am currently using PyTorch 1.7.0. However, I am looking at using a library that claims a dependency on pytorch3d 0.2. I understand not continuing to support older versions (in the sense of bugfixes, etc.) but continuing to host them seems pretty common. For example, pypi (and github) hosts every version ever released. Could you go into more detail about what your concern about hosting older versions is?

Alternatively, I could try using the latest version (0.5) since it looks mostly compatible with v0.2

[bottler]

PyTorch3D 0.2 was older than PyTorch 1.7 and so there never would have been a build for that combination. Much of the code would still be working though, so I think if you installed PyTorch3D 0.2 from source (which should be easy by installing the dependencies and running pip install "git+https://github.com/facebookresearch/pytorch3d.git@v0.2.0") the library may work.

Because we can't match the dependencies easily using PyPI, we couldn't keep versions around and tell downstream packages that they can can rely on a pip freeze to help users. I'd rather force people to worry about their combinations of versions than make it easy to install a non-working combination of packages. Conda is the recommended package manager for PyTorch3D builds and it makes these problems go away.

[scott-vsi]

Thanks! I will try compiling the source.

Just to continue the other thread (and if this is out of scope for this project, then just disregard) but I gather the problem is that while you could host your own pytorch3d+cu111 wheels, there is no good way to say this package depends on torch+cu111. So someone might already have PyTorch installed and that dep would seem to be satisfied but things wouldn't work.

One alternative would be to continue to host the wheels but not in a PEP 503 compatible repository (just list the URL to each wheel in a Previous Versions section like PyTorch does). As a user that would make it easier for me. I can figure out which wheel to download more easily than figuring out how to download/install the necessary compiler and dependencies needed to compile from source.

[bottler]

I will try compiling the source.

I wasn't clear why you couldn't just use conda and install PyTorch3D and its dependencies, then install the rest of what you want with pip in the same environment.

One alternative would be to continue to host the wheels but not in a PEP 503 compatible repository (just list the URL to each wheel in a Previous Versions section like PyTorch does).

That's your original request basically. It would be possible but I don't think it would be widely useful.

[scott-vsi]

I would like to add this package to an existing pip development environment used by my group so I can't convert over to conda.

That's your original request basically. It would be possible but I don't think it would be widely useful.

Fair enough. I disagree. But thats ok, I can try to compile from source or use v0.5.

EDIT: FYI for anyone who wants to compile pytorch3d v0.2.0 (or v0.2.5) from source, this is what I did:

pytorch3d wheels are built in the pytorch/manylinux-cuda102 docker image, which is built from this Dockerfile. Based on this, I was able to compile pytorch3d v0.2.0 into a wheel in my environment, which is based on nvidia/cuda:10.2-devel-centos7

yum install -y centos-release-scl
yum install -y devtoolset-7-gcc devtoolset-7-gcc-c++ devtoolset-7-gcc-gfortran devtoolset-7-binutils

yum install -y which python3-pip python3-devel
pip3 install -U pip

curl -L https://github.com/facebookresearch/pytorch3d/archive/refs/tags/v0.2.0.tar.gz | tar -xz
pushd pytorch3d-0.2.0
    PATH=/opt/rh/devtoolset-7/root/usr/bin:$PATH
    LD_LIBRARY_PATH=/opt/rh/devtoolset-7/root/usr/lib64:/opt/rh/devtoolset-7/root/usr/lib:$LD_LIBRARY_PATH
    export BUILD_TYPE=wheel
    export CU_VERSION=cu102

    # based on https://github.com/facebookresearch/pytorch3d/blob/v0.2.0/packaging/build_wheel.sh
    pip install wheel numpy torch==1.6.0 torchvision==0.7.0
    source packaging/pkg_helpers.bash
    setup_cuda
    IS_WHEEL=1 python3 setup.py bdist_wheel

    # or call build_wheel.sh directly
    #export PYTHON_VERSION=3.6
    #export PYTORCH_VERSION=1.6
    #export VERSION=0.2.0
    #rm -y /usr/bin/python
    #ln -s /usr/bin/python3 /usr/bin/python
    #./packaging/build_wheel.sh

    pip3 install dist/pytorch3d-0.2.0-cp36-cp36m-linux_x86_64.whl
popd
python3 -c "from pytorch3d.structures import Meshes" # simple test

[EDITED forgot to call setup_cuda]

[github-actions]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days.