https://pantsbuild.org/ logo
c

chilly-librarian-83669

12/09/2018, 8:36 PM
we have relatively complex packaging needs. We are currently using sbt, sbt-native-packager and a number of custom plugins. It really feels like we’ve recently crossed over the boundary of what it really intended for. AFAICT, bazel considers this out of scope. What is the pants perspective on packaging & deployment?
a

aloof-angle-91616

12/09/2018, 8:45 PM
that is a good question that someone besides me can answer more effectively, but we do support e.g.
jvm_binary()
and
jvm_app()
which bundle together resources and code, and we do (separately) support publishing to external package repos. the deployment part is pretty extensible, from my personal (limited) experience -- last week was twitter hackweek and i was able to make it possible to produce a native executable using the graal vm from any
jvm_binary()
or
jvm_app()
which has zero startup time (i am going to make a pull request today or tomorrow). on a separate angle, the c++ support we've been improving makes it possible to develop e.g. tensorflow custom operators without having to use bazel or control the environment at all, since we provide the compiler and linker with our very slick interface for providing binary tools, which is something that bazel will likely never ever do. so on the end of at least supporting the use of external tools for packaging, i believe pants allows the integration of external tools without having to rewrite the world. i'm not familiar enough with
sbt-native-packager
and friends but pants also has fantastic support for integrating jvm tools into tasks (i was able to do the graal native image bit to e.g. run scalafmt), so depending upon the workflow, i suspect you will be able to integrate jvm tools that aren't extremely sbt-specific without a huge amount of difficulty. there is definitely some documentation about the use of jvm tools in tasks but i don't know where it is off the top of my head.
(not sure if that addresses your specific concern about packaging/deployment)
c

chilly-librarian-83669

12/09/2018, 8:50 PM
I think it does, several things in there to digest.
a

aloof-angle-91616

12/09/2018, 8:51 PM
yes, i'm trying to improve my communication
c

chilly-librarian-83669

12/09/2018, 8:51 PM
and exciting to hear about graal native executables from
jvm_binary
or
jvm_app
a

aloof-angle-91616

12/09/2018, 8:52 PM
yes, on our internal repo it was able to match exactly the time taken by a warm nailgunned scalafmt on a largeish target set using the silliest possible parallelism strategy
c

chilly-librarian-83669

12/09/2018, 8:52 PM
me too 🙂
👍 1
a

aloof-angle-91616

12/09/2018, 8:52 PM
and not having to have a warm nailgun means more ram for developers etc
c

chilly-librarian-83669

12/09/2018, 8:53 PM
having full process isolation & observability with nailgun-like memory and startup characteristics would be awesome
a

aloof-angle-91616

12/09/2018, 8:55 PM
we're developing jvm remote compilation and test execution in this github project: https://github.com/pantsbuild/pants/projects/7 and in addition to the rsc integration it seems very well suited to make all jvm code pretty instant (and the performance of the native image only loses out in pathological cases, from my very little experience)
the remote execution api was actually developed with bazel so the backend for the remote execution can be switched out