-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Repeatedly breaking fbapipublicfiles (central list) #1401
Comments
We are right in the middle of releasing 0.7.2. I have had to pull the wheels down. |
Yeah, I think I don't understand why the wheels need to be pulled down during new releases - the wheels are named with the semantic version number - why can't pytorch3d leave the wheels under the install link (since the wheels contain the semantic version in their name) and maintain a latest wheel to help automate installation? |
@bottler the current approach means that our builds + tests break whenever you do a release because the links break - can you just leave the link with a deprecation warning? |
@bottler how do y'all recommend external folks use this library? Since the linux wheels aren't pushed to pypi, we have been depending on the ones placed in fbapipublicfiles. If the standard deployment practice makes the previous version unavailable then this will break our build every time there is a release. |
The wheels on fbaipublicfiles are there for a particular purpose - supporting the tutorials. We don't have a proper archive and distribution system for wheels. With the current system, it doesn't make sense to leave old ones up because when we stop supporting a particular dependency combination a pip install would leave the user with a non-latest version. These wheels are not reliable. If you have a downstream CI or automated process can it not use conda? Or save the wheel you are using? Release 0.7.2 has just happened. The wheels available are cuda 11.3 with PyTorch 1.11.0 and 1.12.0, and cuda 11.6 with PyTorch 1.13.0. These are all with Python 3.8, 3.9 and 3.10. I plan to add cuda 11.6 with pytorch 1.13.1 soon. I intended to have cuda 11.3 with pytorch 1.12.1 as well (which is a combination we previously had) but I am having trouble building that. |
Unfortunately not since conda and pip/virtualenv don't seem to play nicely together. This is the first library we've come across in ~2 years that has a conda-only approach to distribution.
Yep, I uploaded the wheels to our internal pypi mirror and updated our requirements to switch to this after the build broke so that we'll be able to opt-in to the next release.
Understood. If you copied these Linux wheels to pypi like y'all are already doing for the Mac wheels though, you would have a proper archive and distribution system that people could use to pip install particular versions. I think it would make your library much more accessible to other non-conda folks like us. |
Copy to pypi how? pypi only allows each version to have only one package per architecture/python_version, right? So how to account for the builds for different cuda and pytorch versions? That's exactly the kind of problem conda is designed to solve. For mac we have no cuda in the equation and we pick only one pytorch version. Doing the same for linux won't please many people.
These got done. The combinations available now are
|
Ahh, I see your point @bottler. I remember pip installing
Sure it will, just upload the version that matches our cuda and pytorch versions and you'll already have one group of happy customers 😉. Kidding aside, not a huge deal for us -- we luckily only need two combinations (one for 3.8 and one for 3.9) so copying wheels to our internal mirror will be an okay compromise moving forward. Appreciate the discussion. |
I'm releasing 0.7.3, which has wheel builds for cu117 and cu118. I haven't removed previous builds. So we now have
|
Builds have been added for versions 0.7.4 and 0.7.5 (just now). Currently
|
Just added
|
Just added
|
py310_cu121_pyt221 now added |
Just added py310_cu121_pyt230/pytorch3d-0.7.6-cp310-cp310-linux_x86_64.whl |
@bottler
Issue: fbapipublicfiles download links for builds are not working
Status: I previously reported this issue when pt3d bumped from 0.7.0 to 0.7.1 at #1366 - it's quite annoying that the previous versions are deprecated during release. As I and others noted on the previous issue, these pre-builds are quite useful because not everyone uses conda.
Request: don't delete/remove access to existing wheels on fbapipublicfiles
The text was updated successfully, but these errors were encountered: