pkg
pkg copied to clipboard
vercel
fix: copy file from snapshot if spawned
This change wraps the spawn internals to copy files from snapshot if needed.
The approach has a few downsides, if in fact the executable needs to read other snapshot files, it will obviously fail. For such advanced use cases copying manually still is a viable option. Perhaps this is undesired behaviour (e.g. creating tmpdirs in pkg's name).
Fixes #1516
@jesec Please feel free to close this PR if you feel this should not be supported by pkg ootb. Otherwise I'll implement the changes you asked for. 👍🏻
Regarding your concerns, while the use case is limited I don't think it's weird.
As you and my PR mentioned, if the executable requires reading other snapshot files it will fail to do so and the developer should copy whatever is necessary to the real fs and spawn from there. But for simply running scripts or other binaries that don't need to read from the snapshot it saves the hassle of writing the copy and cleanup logic.
We at Prisma have a similar use case, where we include multiple binaries (written with Rust) in our Node based CLI and then spawn short running or even long running processes that we interact with from our code (some more information at https://www.prisma.io/docs/concepts/components/prisma-engines). (We indeed would even fall into the limitations: The binaries are fully standalone, no libraries or anything, and we do not read any other files from the file system)
Right now we have custom code in the CLI that detects the pkg filesystem (/snapshot) and then copies the file to a new tmp folder that we create. That works ok, but because of missing comments it recently almost got refactored away (Caught thanks to good tests). It would be very nice if pkg could take care of handling that by itself.
I'm unsure why running this pkg command would (sometimes) fail since my last commit. Why would pkg not have permission to open the output file a second time?
@kldzj no clue, I'm sorry. @jesec ?
I think there is something wrong with the virtual environment of GitHub Actions.
Meanwhile, I still don't like the idea. However, I am giving some thought to a general mechanism to allow users to extract some files from the snapshot. I am tied up with some other matters at the moment, and I will make the decision when I have more time.
I have a case like @janpio. A cli that should run some tasks in Windows and Linux. There is a pre-builded application for each SO (.exe | .AppImage) but the idea now is merge both into a single CLI based on the old ones. It'll be nice to have the option to build executable with pkg. As @kldzj mentioned, yes is a limited case but not necessary weird.
This pull-request is stale because it has been open 90 days with no activity. Remove the stale label or comment or this will be closed in 5 days. To ignore this pull-request entirely you can add the no-stale label
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}