-
Notifications
You must be signed in to change notification settings - Fork 2.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
Instructions for installing PyTorch #6409
Comments
Solution 1 seems infeasible when working in a team with machines on different operating systems, due to the need of providing the complete URL of the wheel including operating system and exact version number. Solution 2 seems to work, but it results in downloading every single PyTorch version that can found, independent on the operating system. I'm running Windows and the download looks like this: A single installation takes around 15-20 minutes at ~250 Mbps. |
Poetry will always download wheels for every platform when you install -- this is because there is no other way to get package metadata from a repository using PEP 503's API. |
Can you elaborate a little on what metadata is needed and why downloading every conceivable version of a package yields that metadata? As mentioned this leads to a ~20min install for one package |
It's not convenient, but it should be feasible with multiple constraints dependencies. |
Poetry requires the package's core metadata aka the However, Poetry is unlikely to grow support for these new APIs until PyPI does, and I think third party repos are unlikely to implement it before PyPI. Eventually support for these APIs will allow for feature and performance parity in Poetry between PyPI and third-party repositories. Until then, we are stuck with the legacy HTML API, which requires us to download every package when generating a lock file for the first time. After your cache is warm you will not need to download again, and on other platforms you will only download the necessary files as the metadata is captured in the lock file. |
What I'm not understanding is that poetry knows I'm on Linux with python 3.8 but it still downloads
Or does that wheel not contain the core metadata that is needed? |
Also there seems to be a second problem going on here unless I've misunderstood the documentation I have this in my pyproject.toml
i.e. Yet poetry is asking that repository for every package I try to install. I thought from the documentation that secondary meant it would go to pypi for any package unless specifically asked to go to that custom repository. |
Poetry constructs a universal lock file -- we write hashes to the lock file for all supported platforms. Thus on the first machine you generate a lock file, you will download a wheel for every supported platform. There is no way to write hashes to the lock file for those foreign/other platform versions without downloading them first. If you want to reduce the scope of this a bit, you can tighten your Python constraint. There is a prototype of a new feature at #4956 (though it needs resurrection, design, and testing work) to add arbitrary markers to let a project reduce its supported platforms as an opt-in.
I think it might be you misreading -- that is the intended and documented behavior. There is a proposal to introduce new repository types at #5984 (comment) as the current |
OK this makes sense now, thanks for the explanation, looking forward to that PR hopefully being merged eventually
I was misreading I see that this is intended behavior
I agree with that and I hope that these new repository types can be implemented |
Can't wait for option 2 to have good performance ! |
Please 👍 on issues instead of commenting me too -- it keeps the notifications down and still shows interest. Thanks! |
Poetry is not yet ready to handle the different versions of PyTorch and Torchvision. See the related issue: python-poetry/poetry#6409
Probably a follow-up issue on the second option:
I guess it tries to load that from the secondary repo as well, and expects to use the keyring due to the unauthorized thing? |
That's #1917 -- our use of keyring hits surprisingly many system configurations in which hard errors occur, and it needs some work. |
@neersighted at least PyPI seems have started work on the new json APi |
Indeed, Poetry 1.2.2 relies on the new PEP 691 support. However, PEP 658 is the real blocker for better performance in third-party repos -- there is a long-running PR blocked on review and a rather combative contributor, but otherwise no major progress on that front. |
could you add a link to the blocked PR? I switched today to method 1 because method 2 took ages. Seems the meta servers are slowed down today... Dependency resolving which takes up to 4000 seconds for method 1 is also insane. And then it failed because I accidental copied 1.12.0 instead of 1.12.1 for the windows release. I really like the idea of poetry but this needs huge improvement. |
We use neither these approaches. As the gpu versions have the same dependencies as the base version this should be OK. The big downsides are
The big upside is that it is very easy to create make scripts for different machines - and that its pretty fast (very important for ci/cd) [tool.poetry.dependencies]
python = "^3.10"
numpy = "^1.23.2"
torch = "1.12.1"
torchvision = "0.13.1" install_cu116:
poetry install
poetry run pip install torch==1.12.1+cu116 torchvision==0.13.1+cu116 -f https://download.pytorch.org/whl/torch_stable.html |
this has essentially been our approach, but in Dockerfiles, gated by a build arg
This also allows installing the CPU version which is smaller a smaller package that lacks the CUDA drivers that come in the normal pytorch package from pypi. They help to slim the images down. |
Hi ! Do you know if it's possible to specify two different optional versions of torch in the pyproject.toml ? I would like to use a cpu version locally and a gpu version on a distant server. You can have a look at an example in this stack overflow post. |
That is something not unlike #5222; the consensus has been that as Poetry is an interoperable tool, no functionality will be added to the core project to support this until there is a standards-based method. A plugin can certainly support this with some creativity and would be the immediate "I want Poetry to support this" use case solution in my mind. |
Thanks for your answer, do you have any such plugin in mind ? |
I don't have any links at hand, but building on top of Light the Torch has been discussed. But if you mean if I know anyone is working on one, no, not that I am aware of. |
For as long as |
I don't see that as a Poetry problem -- the issue is that there is an unmet packaging need, and no one from the ML world is working with the PyPA to define how to handle this robustly/no one from the PyPA has an interest in solving it. Likewise, there is no interest in Poetry in supporting idiosyncratic workarounds for a non-standard and marginally compatible ecosystem; we'll be happy to implement whatever standards-based process evolves to handle these binary packages, but in the mean time any special-casing and package-specific functionality belong in a plugin and not Poetry itself. |
@QuentinSoubeyranAqemia I've not had any luck with dependency groups and extra's - i.e. I get the same as #6409 (comment) Thanks for the environment markers pointer, that should be useful. I'd still like to be able to conditionally install the CPU or GPU verison on linux as well though, I quite often have to switch between CPU or GPU docker images so most of my projects now use poetry for the base sagemaker/boto dependencies but the containers I build for ML pipelines all use requirements.txt |
As detailed in the summary, this is currently not possible. This is a limitation of the python's packaging spec, it's not inherent to poetry. The best you can do to my knowledge is switch based on your platform. Note that when exporting poetry-managed to requirements.txt using poetry-export, you can select poetry dependency groups as you please with |
@QuentinSoubeyranAqemia that’s where I get frustrated with poetry - on the home page it’s advertised as “PYTHON PACKAGING AND DEPENDENCY MANAGEMENT MADE EASY” but in reality everything I’ve read in here indicates the focus is more or less only on packaging and the associated standards compliance - there’s a use case for dependency management without packaging which hopefully will see improved support over time. I need to take a closer look at ‘poetry-export’ - it could be useful |
A well functioning solution for installing I use Ubuntu (WSL) and Python version 3.12. You find the url for the right wheels file from pytorch getting started. Here I use the cuda 12.1 version. You first change the source for where poetry tries to find wheels for pytorch with: poetry source add --priority=explicit pytorch https://download.pytorch.org/whl/cu121 Your [tool.poetry.dependencies]
python = "^3.12"
torch = {version = "^2.3.1+cu121", source = "pytorch"}
[[tool.poetry.source]]
name = "pytorch"
url = "https://download.pytorch.org/whl/cu121"
priority = "explicit" It is superimportant that the priority is set to You can then continue to install PyTorch with CUDA support by running the following command in the terminal: poetry add torch --source pytorch |
@david-waterworth I have a similar use case wherein I use it for both packaging and dependency management. So while packaging doesn't work right now, it works pretty good for dependency management. I use the following config for example:
You can no basically install with cpu, gpu or no dependency with |
With Poetry 1.8.3 this does not work. It just always installs the version from the [tool.poetry.dependencies] section (cpu flavor in this case).
This does not work with poetry 1.8.3 either. With the given toml file (using Python 3.11), The lock file contains two [[package]] blocks for torchvision, one with the cpu flavor, and the other for cuda. The extras blocks looks like this.
I am using Poetry installed from the installer (https://github.com/python-poetry/install.python-poetry.org) on Ubuntu 23.04. Could you please elaborate on what version you are using (OS, installer source)? |
@stf976 there's a slight variation of that I've created this repo to help others find a setup that works for CPU and GPU installs. See if you find it useful. |
Thanks for pointing this out. I just debugged and realized that there needs to be a dependency that needs to force
A few things of note:
Hope this helps |
With the additional package it works here too (tested with poetry 1.8.3), thanks a lot! It is now possible to switch between torch flavors and install the right packages using the --with cpu and --with cuda parameters. I also tried it with newer versions of pytorch (torch-2.3.1 and torchvision-0.18.1), and that worked as well. Unfortunately, Overall it seems like a handy solution to the open issue, but it does not work with the current version of poetry in all cases. |
Inspired by the solution of @shuvamg007, I found another solution that I think is easier to read and understand. The main idea is to specify only the versions of I tested the To install torch-cpu:
To install torch-gpu:
Hope this can help !
|
I have play around on install PyTorch on my poetry project. Solution about It only work on 2.2.2 after that it would just show message The configuration i am using
|
Thank you for the setup, I have tried your repo and it works as described. I found the issue I encountered is really related to the lock file. If a lock file is created with When there is not lock file present, the installation works as described in your repo. Inspecting the lock file shows both cpu and cuda packages are listed, but it seems there is no way to know for poetry which belongs to the cpu extras and which to cuda, because both packages have the same name and no related metadata. So in summary, the installation using your config works as described. Combining the config with lock files or exporting to |
this seems to work for me poetry 1.8.3 [tool.poetry.dependencies]
torch = { version = "2.1.0", source = "pytorch" }
[[tool.poetry.source]]
name = "pytorch"
url = "https://download.pytorch.org/whl/cu121"
priority = "explicit" |
Anyone got a working pyproject.toml for ROCm? |
After some trial and error I think I know why it sometimes works and sometimes won't when using on rocm. poetry works, but pytorch didn't have prebuild wheels for every combination of torch/rocm/python. For example, only torch 2.4 are build for rocm6.1, the old one are kept in rocm6.0 and rocm5.6.
So when using rocm, I think manually check the version available in the source and directly specify it will works better. Here's my declaration: [tool.poetry.dependencies]
torch = { version = "^2.0", source = "torch-rocm" }
torchvision = { version = "^0.16", source = "torch-rocm" }
[[tool.poetry.source]]
name = "torch-rocm"
url = "https://download.pytorch.org/whl/rocm5.6"
priority = "explicit" be sure to check the python version marker too! if one aren't build for rocm you will face the same issue. |
I'm having the same issue here. When running just
|
When trying @tfha approach I get
Produces:
Solution: Found here #7250 (comment) poetry add torch --source pytorch --no-cache |
If you have an intel chip mac, any version past 2.2.2 is unsupported without leveraging conda pytorch/pytorch#114602 |
The solutions described above here and here mostly work, but I noticed that if I re-run the install command (with or without with the sync flag) again after an install, poetry will flip the install to the other version regardless of which flags I've passed. For example, I cloned the repo provided by @lucaspar and simply ran the suggested command over and over:
And poetry 1.8.3 would toggle between the CPU and GPU versions indefinitely: |
Issue
As mentioned in issue #4231 there is some confusion around installing PyTorch with CUDA but it is now somewhat resolved. It still requires a few steps, and all options have pretty serious flaws. Below are two options that 'worked' for me, on Poetry version
1.2.0
.Option 1 - wheel URLs for a specific platform
cu116-cp310-cp310-win_amd64.whl
to see the matches fortorch
,torchaudio
andtorchvision
pyproject.toml
file add the URLs like:poetry update
. It will download a lot of data (many GB) and take quite some time. And this doesn't seem to cache reliably (at least, I've waited 30 minutes+ at 56 Mbps three separate times while troubleshooting this, for the exact same wheels)Note that each subsequent
poetry update
will do another huge download and you'll see this message:Option 2 - alternate source
This seems to have worked (although I already had the packages installed) but it reports errors like
Source (torch): Authorization error accessing https://download.pytorch.org/whl/cu116/pillow/
, but I think they get installed anyway (maybe a better message would be "Can't access pillow at 'https://download.pytorch.org/whl/cu116', falling back to pypi")Also, if you later go on to do, say
poetry add pandas
(a completely unrelated library) you'll get a wall of messages like:This happens with or without
secondary = true
in the source config.Maintainers: please feel free to edit the text of this if I've got something wrong.
The text was updated successfully, but these errors were encountered: