Should (can?) the Poetry target generator produce separate resolves for dev and release?

[wlritchi]

From the docs, we have this example of some Poetry dependencies:

[tool.poetry.dependencies]
python = "^3.8"
requests = {extras = ["security"], version = "~1"}
flask = "~1.12"

[tool.poetry.dev-dependencies]
isort = "~5.5"

In a typical Poetry development and release workflow, developers and CI test steps would install all of these dependencies, but the final artifacts would depend only on requests and flask. From the same docs, we see that the result of the poetry_requirements(...) generator is spiritually equivalent to:

python_requirement(
    name="requests",
    requirements=["requests[security]>=1,<2.0"],
)
python_requirement(
    name="flask",
    requirements=["flask>=1.12,<1.13"],
)
python_requirement(
    name="isort",
    requirements=["isort>=5.5,<5.6"],
)

This representation does not encode any details about which requirements are required at runtime vs required only for development and testing. As a developer new to Pants, and attempting to migrate from Poetry, it's not clear to me if or how I need to express the distinction. Are resolves (part of) Pants' strategy for separating dev requirements from runtime requirements? If so, should a single poetry_requirements(...) produce requirements for multiple resolves? Should multiple poetry_requirements(...) generators be used?

[rbuckland]

I am not an expert, but this may assist.

When pants produces a python package, it automatically infers the dependencies, the libraries, that are used (by following the imports). I found the following references to this feature in pants

• https://blog.pantsbuild.org/dependency-inference/
• https://www.google.com/search?q=site%3Apantsbuild.org+infer

This means that separating the dependencies in the pyproject.toml is good hygene, however when pants publishes the wheel, it will only include references to the dependencies required for runtime.

[kaos]

This is true. Pants does not need the distinction of production and development requirements, as you provide a "universe" of libraries to pick from, and only the ones actually used will be included. So any libraries exclusively imported by test code for instance, will never show up in production.