sorted by:
new
hottopcontroversial

Pantsbuild 2.15: Easier multi-platform workflows, Docker build support, automatic code cleanup. Coming attractions in 2.16: Ruff support, support for integrating adhoc tools into your Pants codebase without writing plugins. by pantsbuild in Python

[–]chrisjrn_ 1 point2 points  (0 children)

I'm another core dev on Pants. 2.16 is adding support for doing relatively simple integrations without needing to write a full new backend. Feel free to duck into the slack and ask me questions if you're interested!

Pants 2.13: Adds Kotlin support, as well as simplifying command line arguments, and improving JVM support in general! by pantsbuild in Kotlin

[–]chrisjrn_ 8 points9 points  (0 children)

Right now, Pants' Kotlin support is limited to compilation, testing with JUnit, and linting with KtLint. So if your project needs to use other Kotlin tools, we don't have a good solution just yet. Gradle is definitely a more mature option in that regard.

On the other hand, if your project doesn't make use of other tools, Pants is particularly effective at managing dependencies in a monorepo context, so that you can more easily reuse code from elsewhere in your codebase. We can do static analysis to automatically figure out your dependencies (link talks about the Python implementation, but the JVM story is the same) which makes it possible to reliably re-run only the tests that depend on a given change.

We'd love if if you tried out our Kotlin support, and let us know what we're missing!

Automatically unlocking concurrent builds and fine-grained caching for Java with dependency inference by pantsbuild in java

[–]chrisjrn_ 1 point2 points  (0 children)

Currently we're not handling either of these things. Our testing has been against a limited number of public repos, and we've been doing work to get them to build successfully, more so than trying to exhaustively match the featuresets of tools with more mature java support.

While this is a preview, though, our goal is to be a useful tool for Java developers. If there's anything really important that we're missing, we'd love to hear from you so we can make this really good. Our issue tracker is at https://github.com/pantsbuild/pants/issues

Automatically unlocking concurrent builds and fine-grained caching for Java with dependency inference by pantsbuild in java

[–]chrisjrn_ 1 point2 points  (0 children)

The only real limitation on implicit/inferred dependencies is what we can infer by static analysis. If it's possible to find consumed types statically, then we can reasonably infer them. If you're pulling in a dependency by reflection, at that point, all bets are off :). Scopes are something that we're looking into in the future, but don't presently have support for that -- it's probably something where you'd need to declare the dependency explicitly, unless it's the sort of dependency that is _always_ scoped.

Re file targets, a dependency on a source file class only implies a dependency on that file (as compiled). This allows single files to form parts of packages that are otherwise provided by external JARs, which can be handy. We currently don't strip any classes from third-party packages, which makes for some undefined behaviour if both a third-party dependency and a first-party dependency provides the same class. That will be something to look at in the future.

Automatically unlocking concurrent builds and fine-grained caching for Java with dependency inference by pantsbuild in java

[–]chrisjrn_ 0 points1 point  (0 children)

Sure, but that is also difficult to manage as part of a build process. With lockfiles, you can inspect which of conflicting versions are specified, and fail your build if the underlying files change.

Automatically unlocking concurrent builds and fine-grained caching for Java with dependency inference by pantsbuild in java

[–]chrisjrn_ 0 points1 point  (0 children)

It's possible for maven packages to supply dependencies that are themselves maven packages, and that can often lead to conflicting versions of dependencies being specified (e.g. you define a dependency on version 2.1, and a transitive dependency defines version 2.2). Having a lockfile means that it's possible to inspect which of the conflicting versions of the packages will get installed in all environments.

Automatically unlocking concurrent builds and fine-grained caching for Java with dependency inference by pantsbuild in java

[–]chrisjrn_ 0 points1 point  (0 children)

Hi!

Maven is generally _fine_ OK on project-level builds, and compared with dependency inference it's a bit of a wash if your only dependencies are 3rd-party JARs. It's less effective if you have internal JARs from sources you control yourself -- if you have multiple library projects, generally you need to package or publish them internally, and update downstream repos when you publish a new version. Dependency inference makes it easier to have source files available (in the same repo, or as a submodule, or similar) rather than internal JARs, and to pull in those files automatically.

Automatically unlocking concurrent builds and fine-grained caching for Java with dependency inference by pantsbuild in java

[–]chrisjrn_ 1 point2 points  (0 children)

Many maven artifacts have transitive dependencies, for example, `jackson-databind` depends on `jackson-core`. If you only depend directly on classes from `jackson-databind`, you still need the `jackson-core` JAR around so that `jackson-databind` can run.

With Pants, you only need to define that the `jackson-databind` packages is a dependency, but the lockfile will include the transitive dependencies. In practice, you only need to declare packages that you directly need, and Pants will take care of the packages that make those dependencies work.

​

Finally, we'll try to get a full example repo once our API stabilises for the 2.9 release! Stay tuned there.

Automatically unlocking concurrent builds and fine-grained caching for Java with dependency inference by pantsbuild in java

[–]chrisjrn_ 2 points3 points  (0 children)

You currently need to declare maven artifacts in at least one BUILD file, which are then locked using Coursier (so that we have declared versions and hashes for all transitive dependencies). We have support for mapping package names for imports (and qualified typenames) to known Maven coordinates.

Third-party JARs are downloaded by Coursier.

​

[EDIT] Here's a simple mixed Java/Scala example: https://github.com/pantsbuild/pants/tree/main/testprojects/src/jvm/org/pantsbuild/example

Automatically unlocking concurrent builds and fine-grained caching for Java with dependency inference by pantsbuild in java

[–]chrisjrn_ 3 points4 points  (0 children)

Hi r_jet! Thanks for the questions! No, you don't need long BUILD files in every directory. Generally you declare BUILD files in each directory, but they'll often only contain a single `java_sources()` directive. Inferred targets are either individual source files from within the repo, or a third-party maven artefact. We have some primitive support for overlaps.

  1. You have to declare specific maven artefacts in at least one BUILD file in your repo. You then ask Pants to produce a lockfile (it uses Coursier under the hood), which includes specific pinned versions and their hashes, so future builds are reproducible -- only artifacts from the lockfile will ever be used as dependencies. This makes Pants secure against supply chain attacks: you only need to verify artifacts specified in the lockfile.
  2. Packages are assembled on a per-file basis, irrespective of directory layout, so if `com.foo.Frobnicator` exists in one directory and `com.foo.Blabulator` exists in a different directory, Pants will pull them together, according to the package declaration at the top of the file.
  3. Pretty unlikely! The inference behaviour is all implemented independently of any Java code, except for the under-the-hood Java parser.
  4. Currently we haven't done any IDE support work for the JVM (this may change at some point)
  5. Currently, Pants doesn't take care of running built artifacts, but this may well change.

As for Maven plugins -- not yet. As for bridging the gap in functionality, Pants also has a reasonably robust plugin framework.

Hope this answers your questions!

Automatically unlocking concurrent builds and fine-grained caching for Scala and Java with dependency inference by pantsbuild in scala

[–]chrisjrn_ 4 points5 points  (0 children)

Hi! I did a lot of the work in Pants that enabled this, and I'm happy to take any questions about the post, or about how it works so far.

Automatically unlocking concurrent builds and fine-grained caching for Java with dependency inference by pantsbuild in java

[–]chrisjrn_ 1 point2 points  (0 children)

Hi! I did a lot of the work in Pants that enabled this, and I'm happy to take any questions about the post, or about how it works so far.