how do I rename a file in a `Digest`? I see `AddPr...
# plugins
f
how do I rename a file in a
Digest
? I see
AddPrefix
and
RemovePrefix
for adding and removing directory prefixes but nothing to change the filename of a file in a
Digest
.
To avoid filename conflicts, I would rather have the result of a
Process
execution use a constant filename which is then changed to the user’s requested output filename (as part of a
package
goal run).
I also thought about constructing a
Digest
directly but that seems to require loading the file into memory in order to use
FileContent
. Is there any way to just reference the file’s fingerprint/size?
h
No intrinsic for that, but it would be good to add. The hard part is figuring out what the API should look Indeed, the workaround is to materialize via
DigestContents
, then use
CreateDigest
. That will be much slower than we want
f
yeah for now I am having the final filename be the output filename in the
Process
but that is not hermetic
👍 1
as for API, allowing
FileContent
to take a union of
bytes
or a digest would solve the issue
taking only
bytes
leaves indirect references
h
or a digest would solve the issue
I think that would need to be a
FileDigest
, not directory digest. You can’t guarantee a directory digest has only one file Note that
FileDigest
is almost never used in Python land, only for
DownloadURL
fyi some prior art with
relocated_files
, but I don’t this will work because it only changes the path prefix and you want to change the file name. https://www.pantsbuild.org/docs/resources#relocated_files
pathlib.Path
might have some inspiration - challenge is finding how to represent it for an arbitrary set of files
f
well a generic “rename” intrinsic may be unnecessary for my use case if I can just reference a file’s digest in
FileContent
You can’t guarantee a directory digest has only one file
I can if it is the result of a
Process
run and only one file was to be captured. (Ignoring the case of no file captured, but my plugin’s code should check for that case any way.)
definitely wouldn’t be multiple files
h
You can’t guarantee a directory digest has only one file
well a generic “rename” intrinsic may be unnecessary for my use case if I can just reference a file’s digest in FileContent
Which would require a new intrinsic like
Get(FileDigests, Digest)
(note the plural) Then,
await Get(Digest, CreateDigest([FileContent(new_path, digest) for digest in file_digests]))
f
ah so
FileDigests
would provide tuples of (filename, digest) in a field
h
Maybe, that could make sense
f
or dict[str, digest]
h
I was thinking it would be a
Collection[FileDigest]
, but yeah, then you have the problem of not knowing the file name
f
does the engine handle
dict
at all vs Collection[Type]?
h
It can, thanks to CPython. Before that, we had to serialize as a
Tuple[Tuple[k, v], …]
f
also, why not just extend
Snapshot
with a
file_digests
field?
that intrinsic should already have the information available
h
For one, overhead. I don’t think we’d want to start sending over FFI the digest for each distinct file in every snapshot
f
good point
h
or dict[str, digest]
This sounds reasonable to me for
await Get(FileDigests, Digest)
. I do have a slight hesitation to elevate the concept of
FileDigest
, as right now plugin authors have no idea it exists unless they use
DownloadURL
. Now we have One More Concept But it may prove worth it, and still you could probably ignore it in most cases
Before adding, we’d want to answer why a
FileDigest
is helpful in the first place. Atm, it sounds like only to be an input to
FileContent
in a
CreateDigest
request
👍🏽 1
f
it is helpful for constructing the
Digest
returned from packaging rules so that the output filename does not need to be given to the
Process
that generates an artifact
(which is my use case…)
but yeah it is useful in cases where an indirect reference to a file is needed
which would be in
CreateDigest