https://pantsbuild.org/ logo
Join Slack
Powered by
<@U06A03HV1> any ideas for how to determine whethe...
# development
h
@witty-crayon-22786 any ideas for how to determine whether we should check that 
[scalac].plugins_global
exists or not?
We default to it being 
3rdparty/jvm/global_scalac_plugins.lock
, whereas most tools default to 
<DEFAULT>
. https://github.com/pantsbuild/pants/pull/14241 means that we now error unless you manually generate the file. The very simple fix is to set the default to be unset
w
if no 
scalac_plugin
targets are set, it shouldn’t need to exist
otherwise it should
so if https://www.pantsbuild.org/docs/reference-scalac#section-plugins-global is empty, the file needn’t exist/be-validated
but if it makes the code cleaner to remove the default location, then ok. just means people have to make multiple config edits to enable plugins.
h
I could change the code to not read & validate the lockfile if the tool is currently configured to have no artifacts. That makes sense to me, and Chris's new validation code already would error if your lockfile had entries but the tool is configured to have no artifacts
w
yea… sounds good then.
it’s vaguely inconsistent for this option to have a default while others don’t, but i think that that ship has sailed
h
and Chris's new validation code already would error if your lockfile had entries but the tool is configured to have no artifacts
Although, actually, this change would mean we don't catch that case. We would eagerly exit before reaching the validation. Is that fine?
it’s vaguely inconsistent for this option to have a default while others don’t, but i think that that ship has sailed
The others do have a default, 
<default>
, which is the one we ship and Just Works. There's no meaningful 
<default>
for 
scalac-plugins
because it's an optional tool
w
i mean that they don’t have a default lockfile location on disk
(even though user lockfiles do, for consistency/ease-of-use-purposes)
i had suggested that tool lockfiles might have default locations as well, and that we use some other property (whether the 
version
had defaulted, for example) to determine whether it should exist
(…but that ship has probably sailed)
you’re right that this is a bit sketchy. would mean that you might have an unused lockfile with content in it sitting in the repo. not the end of the world, but combined with wanting consistency with other tools, maybe it is best to default to 
<default>
https://pantsbuild.slack.com/archives/C0D7TNJHL/p1643069038280100?thread_ts=1643067826.278200&amp;cid=C0D7TNJHL
h
maybe it is best to default to <default>
If we do that, then we'd be loading a completely empty lockfile. Is that fine? It isn't wrong to do, just weird. It would make this code simpler & avoid the issue w/ unused lockfile
w
If we do that, then we’d be loading a completely empty lockfile. Is that fine?
from memory only, right? it wouldn’t be empty if you actually specified requirements
yea, it seems fine for the builtin/<default> lockfile to be empty
h
Via 
importlib.resources
.
it wouldn’t be empty if you actually specified requirements
If that happens, we will eagerly error that the <defualt> is not compatible and you need to set a custom path. So, the <default> will always be empty
w
right
Open in Slack
PreviousNext
Powered by