PDM sync/install parse all dependencies, regardless if they are included or not

[liran-cohen-hs]

Describe the bug

we have an "editable-inner" as well as "inner" dependency groups
in the newest PDM version (2.22.2) when we install in our CI and don't include the "editable-inner" group, it still tries to parse it and fails (since we don't have the local version of the editable dependency)

To reproduce

Example pyproject.toml

[project]
name = ""
version = ""
description = ""
authors = [
    {name = "liran", email = "[email protected]"},
]
dependencies = [
    "gunicorn==20.1.0",
]
requires-python = ">=3.9,<3.10"
readme = "README.md"
license = {text = "MIT"}


[project.optional-dependencies]
inner = [
    "config-resolver @ git+ssh://[email protected]/HiredScore/[email protected]"
]
[build-system]
requires = ["pdm-backend"]
build-backend = "pdm.backend"

[dependency-groups]
editable-inner = [
    "-e file:///${PROJECT_ROOT}/../config-resolver#egg=config-resolver",
]

and run:
pdm sync --prod -G inner

Expected Behavior

I expect the PDM sync command to ignore the "editable-inner" group (as happened pre 2.22.2) and install gunicorn and "config-resolver" from github

Environment Information

PDM version:
2.22.2
Python Interpreter:
/Users/liran.cohen/hiredscore/git/screenit/.venv/bin/python (3.9)
Project Root:
/Users/liran.cohen/hiredscore/git/screenit
Local Packages:

{
"implementation_name": "cpython",
"implementation_version": "3.13.1",
"os_name": "posix",
"platform_machine": "arm64",
"platform_release": "23.6.0",
"platform_system": "Darwin",
"platform_version": "Darwin Kernel Version 23.6.0: Thu Sep 12 23:35:10 PDT 2024; root:xnu-10063.141.1.701.1~1/RELEASE_ARM64_T6030",
"python_full_version": "3.9.5",
"platform_python_implementation": "CPython",
"python_version": "3.9",
"sys_platform": "darwin"
}

Verbose Command Output

reproduced locally:

See /Users/liran.cohen/Library/Logs/pdm/pdm-install-puk9rq8i.log for detailed debug log.
[RequirementError]: file:///${PROJECT_ROOT}/../config-resolver#egg=config-resolver: Editable requirement is only supported for VCS link or local directory.

Additional Context

last couple of log lines:

File "/opt/homebrew/Cellar/pdm/2.22.2/libexec/lib/python3.13/site-packages/pdm/installers/base.py", line 96, in candidates
    for req in (self.requirements or chain.from_iterable(self.environment.project.all_dependencies.values()))
                                                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/opt/homebrew/Cellar/pdm/2.22.2/libexec/lib/python3.13/site-packages/pdm/project/core.py", line 457, in all_dependencies
    return {group: self.get_dependencies(group, resolve_include=False) for group in self.iter_groups()}
                   ~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/opt/homebrew/Cellar/pdm/2.22.2/libexec/lib/python3.13/site-packages/pdm/project/core.py", line 441, in get_dependencies
    req = parse_line(line)
  File "/opt/homebrew/Cellar/pdm/2.22.2/libexec/lib/python3.13/site-packages/pdm/models/requirements.py", line 487, in parse_line
    return parse_requirement(line[3:].strip(), editable=True)
  File "/opt/homebrew/Cellar/pdm/2.22.2/libexec/lib/python3.13/site-packages/pdm/models/requirements.py", line 528, in parse_requirement
    raise RequirementError(f"{line}: Editable requirement is only supported for VCS link or local directory.")
pdm.exceptions.RequirementError: file:///${PROJECT_ROOT}/../config-resolver#egg=config-resolver: Editable requirement is only supported for VCS link or local directory.

I suspect it's related to this: #3361
also, downgraded PDM and it resolved it

Are you willing to submit a PR to fix this bug?

• Yes, I would like to submit a PR.

[frostming]

Your project file doesn't seem right:

1. Editable dependencies cannot be defined under dependency-groups, but under tool.pdm.dev-dependencies, because the former does not support them.
2. You cannot lock different versions of the same dependency in the same lock file. You need to use separate lock files

You'd better not rely on a buggy behavior from an older version that occasionally works for your case.

[liran-cohen-hs]

as for 2- we do use different lock files, didn't mention it but it worked perfect until the latest version
I actually changed from tool.pdm.dev-dependencies to dependency-groups recently because that's what I understood from the latest documentation
I will try to revert and test again in 2.22.2

[liran-cohen-hs]

@frostming same behavior
I have the following sections: dependencies, inner (under [project.optional-dependencies]), editable-inner (under [tool.pdm.dev-dependencies])
locked 2 different lock files successfully
verified them with --check
and still pdm sync --prod -G inner seems to try and resolve the editable inner

[frostming]

and still pdm sync --prod -G inner seems to try and resolve the editable inner

What is pinned in pdm.lock? What is the value of metadata.groups in the lock file?

[liran-cohen-hs]

and still pdm sync --prod -G inner seems to try and resolve the editable inner

What is pinned in pdm.lock? What is the value of metadata.groups in the lock file?

[metadata]
groups = ["default", "dev", "inner"]

we also have an empty "dev" group under [dependency-groups]
could it be the issue ?
I think naming the group "dev" kinda messes the thing with keywords used in PDM (?)

[frostming]

Is the config-resolver editable in pdm.lock?

[liran-cohen-hs]

Is the config-resolver editable in pdm.lock?

not in it's editable mode, in it's github version:

[[package]]
name = "config-resolver"
version = "5.0.0"
git = "ssh://[email protected]/HiredScore/config-resolver.git"
ref = "5.0.0"
revision = "XXX"
summary = ""
groups = ["inner"]

[frostming]

Oh, you mean the editable dependency is parsed, not installed. Then yes, it will be parsed at installation stage, this is the design.

[liran-cohen-hs]

Oh, you mean the editable dependency is parsed, not installed. Then yes, it will be parsed at installation stage, this is the design.

but the bug is still here, I am trying to install the non-develop without editable dependencies version and it tries to parse the editable version and therefore fails (because we don't clone all repositories in our CI process)