https://pantsbuild.org/ logo
h

hundreds-father-404

01/24/2022, 11:43 PM
@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

witty-crayon-22786

01/24/2022, 11:56 PM
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

hundreds-father-404

01/25/2022, 12:02 AM
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

witty-crayon-22786

01/25/2022, 12:03 AM
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

hundreds-father-404

01/25/2022, 12:03 AM
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

witty-crayon-22786

01/25/2022, 12:04 AM
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

hundreds-father-404

01/25/2022, 12:10 AM
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

witty-crayon-22786

01/25/2022, 12:10 AM
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

hundreds-father-404

01/25/2022, 12:11 AM
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

witty-crayon-22786

01/25/2022, 12:12 AM
right