Allow different versions in (dev) sections

Is your feature request related to a problem? Please describe.

I would be very helpful if versions are resolved/locked separately for different sections. Currently, the pdm.cli.actions.do_lock procedure locks whatever the highest version between all sections is. pdm.cli.actions.do_sync then looks at the lock file and installs the version it finds there, regardless of the specification given in the section that it is locking for.

pdm.cli.actions.do_lock appears to mention this feature in the TODO at the top of the function, but I could not find a github issue for it.

Describe the solution you’d like

A simplified example pyproject.toml would be

dependencies = [
    "pdm"
]

[tool.pdm.dev-dependencies]
dev = [
    "-e pdm @ git+https://github.com/pdm-project/pdm"
]

pdm install --prod would install the latest version from the package index, while pdm install -d would install the package from the git repo.

[BrutalSimplicity]

@frostming Any new thoughts on how to approach this. I’ve currently taken your naive approach above and run the install in parallel for all combinations of dependency groups specified by the user (i.e. main/local, main/deploy, main/prod), and then generate a requirements file for each configuration that is stored in the repo. This solution allows us to use the correct version of our project dependencies during local development, local deployment, and production release. However, I’m not happy with the solution although it works pretty well for us so far.

A rather brute method is to generate a sub-resolver each time it encounters a “branch”. And finally the results from all sub-resolvers get merged to format the lockfile. But this approach apparently slows down the whole dependency resolution, making the situation worse.

Some thoughts:

If this is an opt-in functionality, is there anything wrong with it being slower?

Perhaps multiple processes can be used to help improve performance in this case.

It seems like the need for this is becoming more common as monorepo strategies are becoming more popular again. It would be nice if pdm could support this case, and in particular, the use case for the same editable and local package being able to live side-by-side. Maybe the latter can be a separate feature/use case.

[andreas-mucha]

I just also want to add that this would be very useful for me. Apart from #1432 which was just merged, this is the only other thing missing for my usual workflow for co-developing different packages.