Instructions for installing PyTorch #6409
Comments
davidgilbertson
added
area/docs
|
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. |
This alternance is exactly what we are struggling with. The reason is that your markers filters are entirely ignored, see issue #7748 . You could only dependency groups (the poetry-only mecanism), i.e. only use |
Summary of current statusAll views below are my own understanding and I might have mis-understood something. If so, kindly tell me and i'll update this summary What is possible regarding torch & poetry
What is not possible
ReasonsThe fundamental problem is that torch hardware-flavor is defined by the source URL of the repository to fetch it from. There are no
and
So we likely need a update of python's dependency and/or version specs to handle that. This thread is becoming long, the above summary tries to gather all that was tried and is known, and make it easier to look for what you need, or see if your solution has already been described. |
Interesting. I couldn't get it to work without Either ways, it's broken. But atleast I can maintain versioning of packages for the time being. TL;DR Latest summary |
|
Thats because poetry dependency resolution includes all groups together and thus checks that all groups are compatible with each other, because you might require IIRC Two dependency with different source URL are deemed incompatible. During dependency resolution (as opposed to install), the solver seems to understand the extra marker, and when it merges the dependency together, it understood this is an "either, or" that doesn't cause an incompatibility. Added that to the summary |
I imagine this would break |
|
It will make a non-functional wheel/sdist which depends on torch but does not declare that dependency, indeed. You're right that the summary doesn't mention that either, it is an important caveat. Added that to the summary |
Note that the Also, another issue many users had was that poetry would download every wheel of a particular pytorch version to compute the hashes. The solution we currently have is to remind the pytorch devs to add hashes to their wheels if the index regresses again. |
Can the devs implement a fix for this? Or is this by-design? |
|
@slashtechno It's by design. The @PyroGenesis Thank you, I added a note regarding |
|
I don't know if it's already been proposed, but I'd like to see some sort of "build target" option (specifically for the non-package mode) which enabled some way of specifying mutually exclusive versions of the same package/group of packages (i.e. torch cpu/cuda/rocm, faiss cpu/gpu etc) based on some target flag. It's a fairly common use case in ML, you often see multiple Without this I find myself getting painted into a corner with poetry (I know work 50:50 between a linux workstation with gpu, and an M3 MacBook and at the moment have to hack together a combination of installing some stuff with pip and the rest with poetry) |
|
@david-waterworth From my own testing, I think you can achieve this effect by marking all dependencies in a group with the Now for your particular use-case of linux workstation and MacBook, this is already possible without the need for any flag: use environments markers (poetry doc), in particular the As an additional note, I think the PyPI's version of torch does work when cuda is not available, it just runs on the cpu. |
|
@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/cu121Your [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 |
|
Do anyone have Simple guide How to update everything (pip install torch, torch2.1.2+cu and whatever) for using SD XL and other model? (after deleting venv folder. When everything fuck's up im just reistall venv) |
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 ! |
and others
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.whlto see the matches fortorch,torchaudioandtorchvisionpyproject.tomlfile 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 updatewill 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 = truein 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: