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?

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.

I think it does, several things in there to digest.

yes, i'm trying to improve my communication

and exciting to hear about graal native executables from

jvm_binary

or

jvm_app

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

me too 🙂

and not having to have a warm nailgun means more ram for developers etc

having full process isolation & observability with nailgun-like memory and startup characteristics would be awesome

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)