https://pantsbuild.org/ logo
Join Slack
Powered by
:thinking_face: ```1145 | target: target...
# development
b
🤔
Copy code
1145 |           target: target.strip_prefix(name.as_ref()).unwrap(),
     |                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected struct `RelativePath`, found struct `Path`
     |
     = note: expected reference `&RelativePath`
                found reference `&Path`
But 
target
is of type 
&RelativePath
and 
strip_prefix
returns `&RelativePath`: https://docs.rs/relative-path/1.5.0/relative_path/struct.RelativePath.html#method.strip_prefix What am I missing?
✅ 1
w
RelativePath
`Deref`s to `Path`… but, uh: note that this isn’t the relative_path crate: we define this one in 
src/rust/engine/fs/src/lib.rs
it’s not a good practice to have colliding methods on a type that implements `Deref`… i think what is happening there is that you’re running the version of the method from 
Path
f
RelativePath
implements 
AsRef<Path>
. so just call 
.as_ref()
on the 
RelativePath
instance.
(and interestingly it implements 
Deref<Target = PathBuf>
)
I wonder if 
RelativePath
should implement 
Deref<Target = Path>
to match 
AsRef<Path>
and then have an 
into_inner
method (and friends) if callers want the contained 
PathBuf
b
.as_ref()
on 
target
and on the result type isn't it
note that this isn’t the relative_path crate: we define this one in
ohhhh
So it's decomposing into a 
Path
so 
strip_prefix
would work. But now I gotta get it back to the world of 
RelativePath
. Bueno
No bueno, lifetime issues 😂
So seems like we might wanna implement 
strip_prefix
on 
RelativePath
?
oh thats not easy 😐
Any reason we don't use the rust stdlib 
RelativePath
?
w
it’s in a crate i think.
no reason that i know of.
@bitter-ability-32190: worst case here, you should be able to call 
RelativePath::new
after the strip_prefix call…?
b
need a reference 😕
w
reference to what? can you push an example?
b
thejcannon:symlinks
in 
<http://directory.rs:1152|directory.rs:1152>
Just modify whats been pushed with my code-snippet in OP
I'll try out the crate (I thought it was stdlib)
w
i don’t repro a compile failure on that branch
b
you need to edit with my code form above
w
k. let me know if you have a repro you want me to look at: i’m not understanding the problem, so will ignore for now
b
I'll just push
from 
symlinks
w
thanks, i repro
ok, i see the problem. and yea, that’s going to be tricky to fix i think.
but … should 
Symlink
even necessarily be holding a relativepath? should be a path right?
because it could be an absolute symlink
yea, this shouldn’t be a 
RelativePath
probably.
b
good point
i didnt think of absolute path when i started
w
yea. it’ll be weird in DigestTrie (will need to ignore them for most operations? i.e. treat them as dead links), but it’s important for the spec that those exist and can be materialized
b
yeah makes sense
hold on!
(I was planning to do absolute after the current bugfix, so damn. so close)
f
as an aside, the REAPI allows servers to specify whether or not they support symlinks target with absolute paths
b
I saw that. Didn't wanna open that box 😅
f
just mentioning in case we want to avoid opening that exact box in this PR 🙂
b
I'm not exactly sure what reprocussions the server has on the client in this case
Open in Slack
PreviousNext
Powered by