Eastwood: always use absolute filenames, internally#187
Eastwood: always use absolute filenames, internally#187vemv wants to merge 1 commit intonedap:mainfrom
Conversation
vemv
force-pushed
the
169--eastwood-absolutize
branch
4 times, most recently
from
e7d449f to
083236c
Compare
vemv
left a comment
vemv
left a comment
There was a problem hiding this comment.
(Ready-ish but I should QA it)
| (doseq [filename all | ||
| :let [file (File. filename) | ||
| absolute (-> file .getAbsolutePath)]] | ||
| absolute (-> file .getCanonicalPath)]] |
There was a problem hiding this comment.
Settling in using getCanonicalPath only seems a good idea:
- one less thing to remember
- importantly, it resolves symlinks, resulting in cache keys that can hit more often
From memory, libs like tools.namespace favor .getCanonicalPath
| (note that this prefix must not be passed to Eastwood itself).") | ||
|
|
||
| (defn lint! [{:keys [options]} filenames] | ||
| {:post [(do |
There was a problem hiding this comment.
A glorified :such-that ;p
An alternative (or complementary) solution would be strengthening ::protocols.spec/filename from present-string? to a string that denotes an absolutized, existing filename.
IIRC a very similar idea was rejected ~1y ago (can't find the link, sorry) so I'm fine with leaving things as-is
There was a problem hiding this comment.
from present-string? to a string that denotes an absolutized, existing filename. IIRC a very similar idea was rejected ~1y ago
I guess the reasoning would be something akin to "don't have side-effecting specs". I.e. a absolute filepath is fine (i.e. leading /), going through the filesystem is not.
It makes generating examples harder and makes a spec unpure / dependent on state outside of it's input
|
(This branch has worked well for me in my personal setup. Will undust this PR soon enough) |
vemv
force-pushed
the
169--eastwood-absolutize
branch
from
083236c to
9b753a4
Compare
vemv
force-pushed
the
169--eastwood-absolutize
branch
from
9b753a4 to
a120efd
Compare
|
Rebased, gonna give it some extra QAing after this updating |
2 participants
Brief
Part of #169
As a prerequisite for #169, I found out that filenames coming from Eastwood reports should be absolute, otherwise they wouldn't match with filenames computed by a 'linter caching' mechanism. Of course, a key mismatch means no cache hits.
This is the data path as of
master:This PR proposes making the data path always
absolutized filename->absolutized filename.QA plan
Verify that Eastwood keeps emitting reports when a fault arises, in vanilla repos and monorepos alike.
Author checklist
Reviewer checklist