David Hotham

the assumption that all distributions of a particular version of a package share metadata is unlikely to be dropped from poetry: cross-platform builds bring enough complication without trying to add...

it's not an optimization, though, because wheels downloaded at this point aren't cached. So downloading the platform-compatible one at this point wouldn't save a later download. we discussed this at...

not the same thing I think this one should be closed, it seems to have boiled down to "poetry assumes that all distributions of a package provide the same metadata...

still not the same thing, but a duplicate of a dozen others (including the one that you found), please stop polluting this unrelated issue

> This problem didn't exist in 1.1.7 As you can see, this issue was raised against poetry 1.1.3. What _has_ changed is that poetry now passes `--isolated` to pip subprocesses,...

this is not broken and should be closed ```toml [tool.poetry.dependencies] python = "^3.10" tensorflow = { version = "1.15.5", source = "tensorflow" } [[tool.poetry.source]] name = "tensorflow" url = "https://tf.kmtea.eu/whl/stable.html"...

Repeating what I said in the other: that poetry-core MR does not do what you think it does (I don't know what part of the discussion has misled you). There...

The way to make open3d work with poetry is for open3d to use the same set of requirements in all distributions, with variations expressed through pep508 markers eg ``` not-arm-64-dependency==1.0.0...

The swat wheel is invalid in many ways, one of them being sufficiently unusual that poetry does not handle it gracefully - all hash values in the `RECORD` are wrongly...

Today, locking and exporting the given pyproject.toml does not give any duplicates in the output. So I suppose this is fixed: ``` astroid==2.3.0 ; python_version >= "3.6" and python_version <...