Was it a purposeful change in 2.10 to no longer allow targets to be defined with sources outside of where the target is defined?

fwiw, that's been a thing in 2.9 as well

In 2.9 we were able to use

python_requirements(
    source="../path/to/legacy/external-requirements.txt",
)

huh. I wasn't able to do that with things like

python_sources

.

Huh didn't realize the old "context aware object factories" allowed you to do that. That was not intentional The reason this is no longer possible is when you change to the new "target generator" mechanism, that the same bans on

../

now get applied

While slightly annoying in my current very specific use case, not allowing

../

seems reasonable. Not allowing

/absolute/paths

seems a bit restrictive, but sure. Why not recognize symlinks though?

re absolute path, a BUILD file can only define targets in your current repository. You can't define a target for

/HOME/some_other_project

I'm not certain re symlinks, I think Stu or John might have more context on that

re: rationale So in this case we were able to work around it by moving the actual

requirements.txt

file into

3rdparty

, and symlinking to it from the legacy location. Pip has no problem following symlinks. If we were starting from scratch we would not need the requirements file in 2 locations, but we only still only partially on pants and too much brittle tooling references the legacy structure. It's a lot nicer for our 3rdpary deps for pants to be

3rdparty:pandas

ah yeah, targets can only own files in the BUILD file's dir or below it. That is key for how things like

--changed-since

works, so we know which targets to consider and which we can ignore