Deploy preview for website ready!

✅ Preview
https://website-j1y1xefak-python-poetry.vercel.app

Built with commit 2a2e4fe.
This pull request is being automatically deployed with vercel-action

Documentation: https://website-l7h0yqigc-python-poetry.vercel.app/docs/configuration/#installerno-binary

@abn I tested it. As far as I can tell it works great and the docs are clear. Kudos!

As I mentioned in the issue, my only concern is whetherpoetry.toml is the proper place to introduce an option about the installation of specific packages. A possible alternative could be to have an extra section in pyproject.toml. E.g.

[tool.poetry.no-binary]
packages = [
    "shapely",
    "pygeos",
]

From a UX point of view, both approaches should be practically equivalent. The poetry.toml one has the advantage that the option can be set via the CLI, too. The pyproject.toml avoids the proliferation of configuration options in poetry config.

That being said, you have a much better understanding of the "spirit" of poetry's configuration so I trust your judgement.

Right now I think this is the best route as the alternative might set incorrect expectations and cause unintended side-effects. Nothing stopping us from iterating on this. But watch this space :).

out of curiosity, can I ask why not have it as an option on a specific dependency? so you could do something like specifying no-binary for a particular platform, etc.?

[tool.poetry.dependencies]
numpy = [
  { version = "^1.20.0", no_binary = true, markers="sys_platform == 'win32'" },
  { version = "^1.20.0", markers="sys_platform != 'win32'" }
]

Part of the reasons are mentioned in #5599 (comment). I do not think this is completely infeasible, however not something we would want to implement right now. And I am still not convinced this is upto the project to decide as this.

In addition to the above, the solution in this PR also applies to indirect dependencies as well. Because, often times the issues faced by users are to do with a package that are not a dependency of the package itself. Ofcourse, you can add it explicitly to the package. So, the inconsistencies it can introduce and lack of an implementation that addresses all concerns are reasons why the dependency specific configuration is not prefered at this point in time.

@abn this isn't working in 1.2b3 for me...

Ohhhhh poetry.toml !

This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.