Hey everyone, I’m trying out Pants to build my Sca...
# general
a
Hey everyone, I’m trying out Pants to build my Scala projects and hitting an error because the version of scalameta used for dependency inference doesn’t support some of the syntax I’m using. Is there a way I can override the version of scalameta that’s used, or do I need to wait for Pants itself to upgrade the version?
I see that 4.8.7 is hardcoded here so I’m guessing I can’t override it but wanted to check anyway
h
Those are the defaults. You can override them with a custom lockfile (I'll post how in a few minutes once I remind myself...)
OK, so first you generate the lockfile by setting up a new resolve:
pants.toml:
Copy code
[jvm.resolves]
my-scala-parser = "foo/bar/scala-parser.lock"
foo/bar/BUILD:
Copy code
scala_artifact(
    name="org.scalameta",
    group="org.scalameta",
    artifact="scalameta",
    version="X.Y.Z",
    resolve="my-scala-parser",
)
(and maybe other artifacts you need, looks like
io.circe:circe-generic
needs a
scala_artifact
too)
Then you generate the lockfile:
Copy code
$ pants generate-lockfiles --resolve=my-scala-parser
Then you set the parser to use your custom lockfile: `pants.toml`:
Copy code
[scala-parser]
lockfile = "foo/bar/scala-parser.lock"
a
Ahh interesting, thank you for spelling this out! I’ll give it a try
I tried this out and I’m getting an error:
Copy code
ValueError: The lockfile foo/bar/scala-parser.lock (configured by the option [scala-parser].lockfile) was generated with different requirements than are currently set via [scala-parser].artifacts. Run `generate-lockfiles --resolve=scala-parser` to regenerate the lockfile.
When I run the command it suggests, the dependencies revert back to their upstream versions
this seems to work without the need for the
[jvm.resolves]
config or
foo/bar/BUILD
Copy code
[scala-parser]
lockfile = "foo/bar/scala-parser.lock"
artifacts = [
  "io.circe:circe-generic_2.13:0.14.15",
  "org.scala-lang:scala-library:2.13.17",
  "org.scalameta:scalameta_2.13:4.14.1",
]
h
Ah, even better. I guess the JVM tool lockfiles are a bit more flexible than their python counterparts.
👍 1