Option to bypass version resolving on specific dependency

Say I have an app that have to be runnable on these boxes:

• Ubuntu, with CUDA 11.4 (which requires the cu111 version)
• Ubuntu, with CUDA 10.2 (cu111 doesn’t work)
• Ubuntu, CPU only
• MacOS

If only for Linux and MacOS, we can use environment markers such as:

torch = [
  {version = "1.8.1", markers = "sys_platform == 'linux'"},
  {version = "1.8.1", markers = "sys_platform == 'darwin'"}
]

But there’re no options for different CUDA versions.

PROPOSAL:

[tool.poetry.dependencies]
#...
torch = {version = "1.8.1", resolve = False}
#...

For production Docker image: Since pytorch with cuda is big (e.g. torch-1.9.1+cu111-cp38-cp38-linux_x86_64.whl is 2GB). Downloading 2GB for frequent builds (CI/CD) is a wast of time, so I built base Docker images with different pytorch/CUDA version. With pip install -r requirements.txt, it detects the pytorch dep is already fit, and moves on. Expecting an option to have poetry install to treat pytorch as fit as well.

For local dev env: Just run the plain pip install xxxx only once for the venv manually, or in poe plugin, if the default one does not fit.

[finswimmer]

Hello @orctom,

without resolving the dependencies, Poetry cannot create a lock file. But this is a core functionality. This is why it is very unlikely that we will implement something like you suggest.

fin swimmer

[neersighted]

Poetry is a voulenteer-maintained project. If it is not suitable for your use case, no one is forcing you to use it, or selling it to you. We are as interoperable with the rest of the ecosystem as we can be; there are no major barriers to other solutions, if they are more appropriate for you.

The simple matter is that no one who regularly works on Poetry or that is deeply familiar with the code is interested in solving this; until someone interested and motivated to get a design that meets your needs steps up, no amount of berating the Poetry maintainers and community will grant your ask.

We’re off-topic for this issue, please direct any more discussion of dependency constraint overrides to #697.