I see in e46a9f2 that the spec this was trying to attach python to was llvm: llvm extends python (in this case) but is not a PythonPackage, so it's implementation of _update_external_dependencies (inherited from PackageBase) is a noop (i.e. no attempt to call detection.by_path).

As noted in #50616 (comment), envs that use concretize_separately (i.e. those w/ unify:false) will fail on develop if they contain external py- packages (with no corresponding python external). So the latest commit experiments with using a SequentialExecutor to detect Python (so that can occur in the context of concretize_separately).

It's probably also worth excluding some/most (non-py-) packages from this check: the logic was added specifically for PythonPackages because they refer to self["python"] outside of phase methods, so that should be ok. I presume we don't want to check isinstance(PythonPackage). llvm is kind of a special case in that it will be commonly referenced as an external (because it is a compiler) and it extends python, so perhaps excluding compiler packages would be a good compromise.

LLVM actually references spec["python"]:

            if "python" in spec:  # lit's Python needs to be set with this variable
                cmake_args.append(define("python_executable", spec["python"].command.path))

Note that it's guarded, so I guess things won't fail if you exclude LLVM, but I think it's worth figuring out why LLVM was special here and why running this check on it failed.

I presume we don't want to check isinstance(PythonPackage)

Probably not, as we don't want the import coupling between core and builtin, but for this very special case I think this would be ok and would avoid that problem while doing no harm:

any([c.__name__ == "PythonPackage" for c in cls.__mro__])

It would at least exclude the things that would've been excluded before, and would allow us to fix this better later (which is the intent).

LLVM actually references spec["python"]

Yes, but inside of a function used by a phase (so when LLVM is external, none of its references to self["python"] will be "tripped").

but for this very special case I think this would be ok and would avoid that problem while doing no harm:

In terms of LLVM, that has the same behavior as 2c52cf9 (which is fine, given the above) but I think it is preferable because it achieves exactly the same inclusion/exclusion as before.