https://pantsbuild.org/ logo
Join Slack
Powered by
<@U021C96KUGJ>: re <https://github.com/pantsbuild/...
# development
w
one thing that @fast-nail-55400 and i were talking about yesterday is maybe trying to use `DownloadUrl`to fetch the input and then feed it to coursier as a file
a
what’s the rationale?
w
i added a comment referring to another ticket on that… i think it was just having fewer mechanisms for fetching things
but it would require specifying a digest for the file… and actually wouldn’t get you file watching.
oh: actually. @ancient-vegetable-10556: one rational for having “local jars” be provided by a 
files
target is that it would get you file watching within the repo
a
Certainly for local files, yes
What’s the rationale for providing a file location to a JVM artifact rather than just making a local JAR dependency?
f
I’ve seen some repos where third party jars were checked into the repo.
a
Yeah, I’ve done it myself, numerous times
f
so a case of “make my classpath literally these jars”
so that would be the rationale
and not much from that point to storing the jar at a URL instead of in the repo
a
Right, but the 
jvm_artifact
(group/artifact/version) machinery doesn’t seem relevant to a local jar
f
it is somewhat relevant in that it provide enough metadata to enable dependency inference, right?
we could also make the coordinate-related fields optional if 
file=
is provided
a
1. We have URLs on JVM artifacts for things we need to download — that enables our coarse, low-network traffic dependency inference 2. We have a separate 
jar
target for local JARs, which is for local files, where we have the ability to scan the JAR for actual provided types
w
it’s all still relevant to coursier: if you’ve given it a local version of something, it shouldn’t download a separate one, and it should include the specified version in its calculations.
f
so 
local_jvm_artifact
(or some better name)
it’s all still relevant to coursier: if you’ve given it a local version of something, it shouldn’t download a separate one, and it should include the specified version in its calculations.
good point
w
also, it needs the transitive deps
a
Do we need users to specify the transitive deps?
f
if users want to use a local jar that has no official coordinates, then the user should just supply “fake” coordinates
a
that makes sense
w
Do we need users to specify the transitive deps?
… good question actually. there wouldn’t be a pom. but the answer lies in coursier’s implementation of the feature
f
there wouldn’t be a pom.
what is the user wants to supply a pom?
w
unclear. would want to look at prior art on that. i know that v1 didn’t support it, but other systems might
f
(doesn’t seem like it would be a case for consuming a local jar , but if users are making jars for publication, then I assume Pants will support poms for publishing purposes.)
also, on the topic of how to specify a download, I’d rather see a separate 
http_archive
target type which downloads the artifact and has a sha256 checksum field. Bare URLs are not conducive to mitigating software supply chain attacks.
☝️ 1
w
@fast-nail-55400: they end up in the lockfile
a
not for things that don’t have a lockfile
w
so, yes in general. but this is a case for which we generate the lockfile for you
a
right
f
I also imagine 
http_archive
as more useful than just for jvm artifacts since it would export its archive for any Pants target that supports 
./pants package
artifacts
and in that case it should have a sha256
w
regarding coursier’s support… it looks like all it entails is plopping the URL on the end of the requirement: https://github.com/pantsbuild/pants/blob/495eccd9ed9e7986358a14e9d4f1d07ed4cf20b0/src/python/pants/backend/jvm/tasks/coursier_resolve.py#L490-L492 … that doesn’t answer whether it tries to fetch/use a POM
@fast-nail-55400: sure, but that’s directly covered by the linked ticket: https://github.com/pantsbuild/pants/issues/13589
Open in Slack
PreviousNext
Powered by