https://pantsbuild.org/ logo
#development
Title
# development
w

wide-midnight-78598

06/17/2022, 7:10 PM
Naming convention question - getting prepped to write some compiler(s) and I want to make sure I'm using reasonable target names: I see
_binary
and I'm assuming that's referring to an artifact that is directly executable? For library-centric, I see
_package
and
_distribution
Then I see a
go_mod
jvm_artifact
and `jvm_war`and maybe
deploy_jar
- which seem to be language-centric So, if I'm creating a static or shared library (let's say C++ or Swift), should I call that
_library
? Because that also used to be an alias for something...
python_sources
maybe?
w

witty-crayon-22786

06/17/2022, 7:35 PM
_binary
,
_distribution
,
jvm_war
, and
deploy_jar
are “shippable artifacts”… they turn into loose files in
dist
which you might ship somewhere, and are mostly consumed by the
package
goal
go_mod
,
go_package
and
*_sources
are more like library code (although
go_package
is odd because it can be packaged or tested or etc)
so, to your question: yea,
_library
or
_sources
likely make sense, assuming that you have some other target type to represent a deployable/shippable thing.
for example: a
swift_binary
target would consume `_library`s and be packagable into a (static?) binary
w

wide-midnight-78598

06/17/2022, 7:41 PM
Thanks for the info, it's still a bit confusing, because isn't
pex_binary
generated via the
package
goal? It's all semantics, but I'm just trying to stick consistent with whatever is desired, so I'm not adding random targets. In my case, I take something like
cxx_sources
and then can be compiled into an executable (
cxx_binary
?) or, I might wrap them into a library (
cxx_library
?)
Ditto for Swift.
The way I kinda interpreted it, was that a
_binary
can be executable, and also used by
./pants run
(though, this thinking might change with the new run on sources stuff`
w

witty-crayon-22786

06/17/2022, 7:42 PM
In my case, I take something like
cxx_sources
and then can be compiled into an executable (
cxx_binary
?) or, I might wrap them into a library (
cxx_library
?)
yea, potentially. the
_sources
/
_library
split might make sense if you would like a separate target that defines a “shippable”/“deployable”/“packageable” library
w

wide-midnight-78598

06/17/2022, 7:43 PM
Yep, that makes sense to me. I view
sources
as something a developer would edit. Libraries/Binaries are generated from sources/files/resources
For the compilable code, sources aren't directly consumable (linked) by a binary or library, they need to be compiled first. Whereas libraries can be consumed directly
w

witty-crayon-22786

06/17/2022, 7:46 PM
sure. but a larger reason for
_sources
/
_library
split might be that you want to have different “deployments” of the same compiled sources, and the settings/fields for the deployment/`_library` are different from the settings/fields for the
_sources
i.e.: think about the data that you need for various tasks
it’s also definitely worth acknowledging that there is prior art on modeling these in
bazel
and `buck`: pants has more CLI goals than they do, and that affects things a bit. but most of “this target needs this data, that target needs that data” applies in both cases.
w

wide-midnight-78598

06/17/2022, 7:48 PM
Ah, okay okay, I think I get that angle. And yeah, I've been looking at Bazel a bit, but in terms of naming conventions, that's a Pants-specific approach, if there are differing semantics. In terms of fields, I'm definitely looking at a whole lot of places. I suck at naming, so I'm not trying to re-invent any wheels 🙂
A lot of this also applies to JS/TS, since there are "bundles" of processed code - so I'm just trying to grok all of what's going on here.