https://pantsbuild.org/ logo
Join Slack
Powered by
Naming convention question - getting prepped to wr...
# development
w
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
_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
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
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
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
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
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.
Open in Slack
PreviousNext
Powered by