https://pantsbuild.org/ logo
Join Slack
Powered by
The errors I'm seeing are: ``` ERROR] Invalid opti...
# general
a
The errors I'm seeing are:
Copy code
ERROR] Invalid option 'path_by_id' under [binaries] in /Users/me/eclipse-workspace/dp/pants.ini
ERROR] Invalid scope [pycheck-pep8] in /Users/me/eclipse-workspace/dp/pants.ini
ERROR] Invalid option 'unused_deps' under [compile.zinc] in /Users/me/eclipse-workspace/dp/pants.ini
ERROR] Invalid scope [scala-platform] in /Users/me/eclipse-workspace/dp/pants.ini
ERROR] Invalid option 'version' under [gen.protoc] in /Users/me/eclipse-workspace/dp/pants.ini
Seems like many of these were refactored or removed. By reading github comments it looks like path_by_id is now under GLOBAL. The rest I haven't figured out what to do with yet. Google and docs come up dry for those.
h
Are you upgrading all at once? I recommend a upgrading major version at a time, so that you can see all the deprecations and it’s less jarring of an upgrade. Whenever we deprecate something, we print a hint about how you should change things to get it working. But that deprecation only lasts one version, and then the next version it gets removed
w
@abundant-london-78114: yea, as eric said: you should bump version-at-a-time and get 
./pants dependencies ::
parsing before you move to the next version. you might not run your CI test suite for every bump, you should definitely at least parse everything, because there are a lot of deprecations
👍 1
a
I was afraid of that. In this case I will need to upgrade and build the entire monorepo 11 times. 😞
Given the build times we have this will take 6 months.
w
@abundant-london-78114: so, see what i said again
a
But I understand what you are saying and why you are suggesting it. Makes sense.
w
i'm saying you don't need to build for each of them
a
Just generate the dependency graph.
w
yep
a
I can try that first.
w
if you can build more of them, then by all means: that would definitely help
but you'll get 99% of the benefits of deprecations by just ensuring that everything is parsing
👍 1
we ought to document this... sorry
a
Makes sense. Thanks.
w
each deprecation has some help attached to it, and lives for at least one major release: https://www.pantsbuild.org/deprecation_policy.html
so getting things parsing on each version ensures that you'll see all the help
👍 1
a
we ought to document this
adding a line about how to use 
./pants dependencies ::
in each version step to the deprecation policy page sounds like a good intermediate step
😀 1
❤️ 1
i'll get that later today i wrote it down
h
I’m afk but do we have a top level article “Upgrading Pants”? If not, would be extremely useful In fact, I’ve never been able to discover the deprecation policy through the site itself. I always have to google “Pants deprecation”. I might have just missed it, but would be great to audit that pages discoverability as well
🤩 1
w
doesn't exist now, but yea... that's roughly what i was thinking of.
💯 1
a
It would be very helpful.
Got to version 1.8. Having trouble figuring out what to do with:
Copy code
WARN] sys:1: DeprecationWarning: DEPRECATED: option 'unused_deps' in scope 'compile.zinc' will be removed in version 1.9.0.dev0.
  Option has moved to `--lint-jvm-dep-check-unnecessary-deps` and is ignored in this location.
Looking at the latest docs I don't see anything about the suggested alternative flag and how to properly put it into pants.ini.
I tried:
Copy code
[lint.jvm-dep-check]
check_unnecessary_deps: ignore
w
@abundant-london-78114: 
./pants help lint
should show something?
(confirming)
@abundant-london-78114: but if all you want to do is ignore unused deps, you can just drop that option entirely
a
k
That is what we want to do.
At least that's what I assume ignore used to do. I can't see the old documentation. I guess I can rollback to the old one and see the help for that option.
w
yep
and in 1.8.0, you should see 
./pants help lint
showing:
Copy code
lint.jvm-dep-check options:
Checks true dependencies of a JVM target and ensures that they are consistent with BUILD files.

--lint-jvm-dep-check-missing-deps-whitelist=<str> (--lint-jvm-dep-check-missing-deps-whitelist=<str>) ..., --lint-jvm-dep-check-missing-deps-whitelist="[<str>, <str>, ...]", --lint-jvm-dep-check-missing-deps-whitelist="+[<str>, <str>, ...]" (default: [])
    Don't report these targets even if they have missing deps.
--lint-jvm-dep-check-missing-direct-deps=<str> (one of: [off, warn, fatal] default: 'off')
    Check for missing direct dependencies in compiled code. Reports actual
    dependencies A -> B where there is no direct BUILD file dependency path from
    A to B. This is a very strict check; In practice it is common to rely on
    transitive, indirect dependencies, e.g., due to type inference or when the
    main target in a BUILD file is modified to depend on other targets in the
    same BUILD file, as an implementation detail. However it may still be useful
    to use this on occasion.
--lint-jvm-dep-check-unnecessary-deps=<str> (one of: [off, warn, fatal] default: 'off')
    Check for declared dependencies in compiled code that are not needed. This
    is a very strict check. For example, generated code will often legitimately
    have BUILD dependencies that are unused in practice.
a
Yeah. I just wasn't clear what ignore on the old option vs on/off on the new option would be. Sounds like off and ignore are the same thing and default is off.
w
yep
a
(we're planning to expose versions of the docsite at permalinks for each release instead of only showing the most recent, but haven't found the time yet. we are hoping to be able to do this in the next few months, along with some other docsite improvements. if you have any more thoughts on how the site/docs could be improved please let us know via slack or github!)
❤️ 1
also, did
Copy code
[lint.jvm-dep-check]
check_unnecessary_deps: ignore
not raise an exception?
Open in Slack
PreviousNext
Powered by