https://pantsbuild.org/ logo
#general
Title
# general
e

enough-analyst-54434

11/10/2020, 2:13 AM
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

hundreds-father-404

11/10/2020, 2:17 AM
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

enough-analyst-54434

11/10/2020, 2:18 AM
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

happy-kitchen-89482

11/10/2020, 3:54 AM
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

average-vr-56795

11/10/2020, 7:40 AM
Possibly controversial opinion: maybe
resources
is too general a target type, which makes it hard to reason about in different languages?
e

enough-analyst-54434

11/10/2020, 5:49 PM
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

hundreds-father-404

11/10/2020, 5:52 PM
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

witty-crayon-22786

11/11/2020, 8:06 PM
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

hundreds-father-404

11/11/2020, 8:21 PM
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