https://pantsbuild.org/ logo
Join Slack
Powered by
It seems source roots have been misunderstood on a...
# general
e
It seems source roots have been misunderstood on average since inception back in ~2010. Maybe it would make more sense to folks to have per-language options with language-specific terminology that all contributed to the global source root configuration? For example PYTHONPATH for 
python
, GOPATH in for 
go
and -sourcepath for 
javac
.
h
Agreed on being misunderstood, and that language specific functionality is more clear. My main concern with language-specific options is how 
resources
would work, which can be used by multiple languages. At a minimum, we should rewrite the docs to lean much more heavily on those language-specific terminology
➕ 1
e
Do we have a 
resources
specific source root today? If not then it just uses the found source root. That works across languages since resource always means the same thing wrt path in the app (in all languages I'm familiar with).
In fact, just like target types (in BUILD files) are arguably a bad abstraction, so too are global source roots. Either a language's rules will use a source root concept or they wont, but they really gain nothing from a global config for this. It probably should be per-language-vertical.
i can't think of any goal (except 
roots
) which uses all the roots!
h
I would be totally up for changing the user-facing concepts to be language specific (esp since nothing would need to change behind the scenes, at least initially anyway).
This makes even more sense when you consider golang, since the GOPATH - which is the relevant user-facing concept - isn't actually a source root in our sense (GOPATH/src is). So asking users to define golang source roots is quite non-idiomatic
a
Possibly controversial opinion: maybe 
resources
is too general a target type, which makes it hard to reason about in different languages?
e
Perhaps, although the concept is the same in every language I've used that supports them. Its true not all languages support resources (natively) - like Rust, but for those that do.
👍 1
h
Agreed with John. Our lessons learned from codegen may be insightful too. In v1, we had targets like 
python_thrift_library
and 
java_thrift_library
referring to the same Thrift code. We simplified that in v2 to only be a single 
thrift_library
, and we use “plugin fields” to add additional fields like 
python_interpreter_compatibility
, along with specific subsystems like 
[python-protobuf]
. This deduplicates BUILD files. I suspect we’d want the same with resources, that it’d be annoying to have 
python_resources
and 
java_resources
referring to the same files.
w
I think that having a unified concept, and having per-language explanations of what it is equivalent to is sufficient. I expect that part of the gap is that we don't say "PYTHONPATH == source root" loudly enough in the docs
👍 1
h
I’m leaning that way too. I think that generally the fewer knobs we have in 
pants.toml
, the simpler. Fewer questions of “wait, which one do I change again?” +1 on updating the docs
Open in Slack
PreviousNext
Powered by