Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Dependency management corrupted in pytorch 2.5.0 #139005

Open
SH2282000 opened this issue Oct 27, 2024 · 5 comments
Open

Dependency management corrupted in pytorch 2.5.0 #139005

SH2282000 opened this issue Oct 27, 2024 · 5 comments
Labels
module: binaries Anything related to official binaries that we release to users triaged This issue has been looked at a team member, and triaged and prioritized into an appropriate module
Milestone
2.6.0

Comments

@SH2282000
Copy link

SH2282000 commented Oct 27, 2024 •
edited by pytorch-bot bot
Loading

🐛 Describe the bug

Expected behavior

When using a project still using python 3.8, the version of Pytorch used should be smaller than 2.5.0.

[tool.poetry.dependencies]
python = ">=3.8"
...
torch = ">=2.0.0, !=2.0.1, !=2.1.0"

Bug description

Nevertheless, the installer (in this case poerty) will return an error verbosing the following:

              |   - Installing pyparsing (3.1.4)
              |   - Installing scikit-learn (1.3.2)
              |   - Installing torch (2.5.0)
              | 
              |   RuntimeError
              | 
              |   Unable to find installation candidates for torch (2.5.0)
              | 
              |   at /opt/poetry/venv/lib/python3.8/site-packages/poetry/installation/chooser.py:74 in choose_for
              |        70│ 
              |        71│             links.append(link)
              |        72│ 
              |        73│         if not links:
              |     →  74│             raise RuntimeError(f"Unable to find installation candidates for {package}")
              |        75│ 
              |        76│         # Get the best link
              |        77│         chosen = max(links, key=lambda link: self._sort_key(package, link))
              |        78│ 
              | 
              | Cannot install torch.

Versions

This happened on a shared runner with Poetry version 1.6.X, I was not able to reproduce it locally.

image

cc @seemethere @malfet @osalpekar @atalman
@Skylion007 Skylion007 added this to the 2.5.1 milestone Oct 27, 2024
@Skylion007 Skylion007 mentioned this issue Oct 27, 2024
Closed
8 tasks
@kit1980 kit1980 modified the milestones: 2.5.1, 2.6.0 Oct 27, 2024
@kit1980
Copy link
Member

kit1980 commented Oct 27, 2024

Please explicitly limit upper torch version for now.

@SH2282000
Copy link
Author

Well, I came with a slightly better workaround for now, which allow later python versions to work with torch 2.5.0 and higher:

The following line

torch = ">=2.0.0, !=2.0.1, !=2.1.0"

got replaced by

torch = [
  {version = ">=2.0.0, !=2.0.1, !=2.1.0", python = ">=3.9"},
  {version = ">=2.0.0, !=2.0.1, !=2.1.0, <2.5.0", python = "^3.8"}
]

in my pyproject.toml

@ezyang ezyang added module: binaries Anything related to official binaries that we release to users triaged This issue has been looked at a team member, and triaged and prioritized into an appropriate module labels Oct 29, 2024
@ezyang
Copy link
Contributor

ezyang commented Oct 29, 2024

@kit1980 is this a problem on our side?

@malfet
Copy link
Contributor

malfet commented Oct 29, 2024 •
edited
Loading

@kit1980 is this a problem on our side?

No, it is not, we simply did not release torch-2.5.0 on 3.8 as it reached EOL in October.

Also, any objections if I'll create a separate label for poetry?

@SH2282000
Copy link
Author

SH2282000 commented Oct 29, 2024 •
edited
Loading

this a problem on our side?

Not sure what is meant by that, but the only concern is that the dependency manager should know which version of PyTorch to use for which version of python, independently than the EOL of certain python version.

That is called "Legacy" and I should not have to manually do the job of the dependency manager because it cannot resolve certain dependencies when used with an earlier version of Python.

create a separate label for poetry?

Is that not a standard process of dependency resolution, what poetry is doing more than any dependency manager?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
module: binaries Anything related to official binaries that we release to users triaged This issue has been looked at a team member, and triaged and prioritized into an appropriate module
Projects
None yet
Milestone
2.6.0
Development

No branches or pull requests
5 participants
@ezyang @kit1980 @Skylion007 @malfet @SH2282000