I didn't see any docs regarding dependency cycles. I thought they were kinda kosher, but I'm seeing

CycleException

(only if I use explicit

python_source

though).

a.py depends on b.py depends (for type-checking) on a.py

BUILD.pants

# no error
python_sources()  
# Error
python_source(name="a", source="a.py")
python_source(name="b", source="b.py")
# Also no error
python_sources(name="a", sources=["a.py"])
python_sources(name="b", sources=["b.py"])

This seems... unexpected

Why? Even without Pants, Python cannot handle import cycles.

But Pants CAN handle it in case 1 and 3? Also Python can handle it, the import is hidden behind

if TYPE_CHECKING

, which in this case it is. (or any other dynamic/delayed importing)

But I don’t recall that dependency inference handles

if

clauses.

Dependency inference for Python just scans for

import

statements at any level in any part of the code. I think you're missing the forest for the trees though. How come when I use a generator there's no error but when not it errors. Seems like an annoying gotcha.

That’s why I asked:

What does dependency inference do in the

python_sources

case?

Using a generator doesn’t imply that the generated targets have dependencies on each other unless the backend opts in to that behavior.

./pants peek a.py b.py

[
  {
    "address": "dirname/a.py:dirname",
    "target_type": "python_source",
    "dependencies": [
      "dirname/b.py:dirname"
    ],
    "dependencies_raw": null,
    "description": null,
    "interpreter_constraints": null,
    "resolve": null,
    "skip_black": false,
    "skip_flake8": false,
    "skip_isort": false,
    "skip_mypy": false,
    "skip_pylint": false,
    "source_raw": "a.py",
    "sources": [
      "dirname/a.py"
    ],
    "tags": null
  },
  {
    "address": "dirname/b.py:dirname",
    "target_type": "python_source",
    "dependencies": [
      "dirname/a.py:dirname"
    ],
    "dependencies_raw": null,
    "description": null,
    "interpreter_constraints": null,
    "resolve": null,
    "skip_black": false,
    "skip_flake8": false,
    "skip_isort": false,
    "skip_mypy": false,
    "skip_pylint": false,
    "source_raw": "b.py",
    "sources": [
      "dirname/b.py"
    ],
    "tags": null
  }
]

The Python backend does not opt in. https://github.com/pantsbuild/pants/blob/f0bdc379bd440e3b622d78e49c31bb3b16c7d4a7/src/python/pants/backend/python/target_types.py#L150

I know the circular import "works" with the generator, because I use it today, and

mypy

doesn't complain on missing import. But for organizational reasons I have to switch to non-generator targets. So this is surprising.

then I don’t know. @hundreds-father-404 knows way more about this detail of the Python backend than I do

lint

, which I assume is where Pants starts grabbing transitive deps.

maybe the

lint

rule should use

CoarsenedTarget

?

I think it's more likely a bug in the detection code which is shadowed by using a generator?

and ensure that `CoarsenedTarget`’s end up in the same partiition

I think

lint

might be a red herring here

Well... poop

yes…

python_sources

=P

For reasons I don't want to go into it's muuuuuch easier to use one-target-per-source for now

regarding that issue though: haven’t thought about it in a long while, but it’s entirely possible that we should remove the restriction entirely. we had it in the first place because i was squeamish about cycles when we first began to allow them. but explicitly specified dependencies are so rare, that it’s not clear it’s adding anything

.... Wait, I have a workaround

the target address include the filename

the

Address

type is what triggers the behavior, so you probably can’t get both the cycle behavior and address the way you want.

done!

I agree w/ adding an option re cycle tolerance. Some people may want to universally enforce no cycles

…or maybe a cycle-check linting backend (disabled by default), with a plugin field to allow it per-target.

so you have an escape hatch