-
-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support placeholders for files. #19
Labels
idea
Ideas that may or may not be good.
Comments
jsirois
added a commit
to jsirois/jump
that referenced
this issue
Nov 9, 2022
Now commands can depend on `{boot.bindings.<binding name>}` placeholders which are satisfied by boot bindings commands that are run exactly once. This is used in the Python example to produce a scie-pants Pants binary that prepares a fully pre-compiled Pants venv that runs at the full speed of a native Pants venv. The boot binding command that creates the venv also uses a private PEX_ROOT and cleans this up in addition to the Pants PEX used to build the venv. The result is an ~/.nce with just the CPython interpreter and a venv that symlinks to it. There is no wasted speed or space as compared to a traditional Pants Python venv (save for the size of the scie binary itself which may be addressed by a-scie#9 or a-scie#19). Closes a-scie#7 Closes a-scie#20
jsirois
added a commit
that referenced
this issue
Nov 11, 2022
Now commands can depend on `{boot.bindings.<binding name>}` placeholders which are satisfied by boot bindings commands that are run exactly once. This is used in the Python example to produce a scie-pants Pants binary that prepares a fully pre-compiled Pants venv that runs at the full speed of a native Pants venv. The boot binding command that creates the venv also uses a private PEX_ROOT and cleans this up in addition to the Pants PEX used to build the venv. The result is an ~/.nce with just the CPython interpreter and a venv that symlinks to it. There is no wasted speed or space as compared to a traditional Pants Python venv (save for the size of the scie binary itself which may be addressed by #9 or #19). Closes #7 Closes #20
jsirois
added
the
in progress
Indicates the assignee is actively working on the item.
label
Nov 16, 2022
jsirois
added a commit
to jsirois/jump
that referenced
this issue
Nov 16, 2022
Files can now either be embedded in a scie or else loaded at runtime via a binding cmd that takes the filename to load as an agument and produces the file content on stdout. Hashing and size checking are still performed by the installer. And example is added that assumes `curl`, `jq` and `bash` are present on the host for doing loading from the internet. Closes a-scie#19
jsirois
added a commit
that referenced
this issue
Nov 16, 2022
Files can now either be embedded in a scie or else loaded at runtime via a binding cmd that takes the filename to load as an agument and produces the file content on stdout. Hashing and size checking are still performed by the installer. And example is added that assumes `curl`, `jq` and `bash` are present on the host for doing loading from the internet. Closes #19
jsirois
added a commit
that referenced
this issue
Nov 21, 2022
Files can now either be embedded in a scie or else loaded at runtime via a binding cmd that takes the filename to load as an agument and produces the file content on stdout. Hashing and size checking are still performed by the installer. And example is added that assumes `curl`, `jq` and `bash` are present on the host for doing loading from the internet. Closes #19
This still needs some doc before closing. |
I'm not sure if scie-jump will house specific docs for ptex, but the ptex docs are up for review in a-scie/ptex#11. |
jsirois
removed
the
in progress
Indicates the assignee is actively working on the item.
label
Nov 26, 2022
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The idea is to extend placeholders from parameterizing commands to also parameterizing files.
Like so:
The idea is a new placeholder
{scie.file.<binding>}
. A file whose name ends in={scie.file.<binding>}
will not be processed by the boot-pack but instead be processed at install time. The protocol would be something like:So if the binding command can accept file json and emit that file on stdout, that's all that needed to hydrate files from elsewhere than the scie itself. Since the config is strict for the scie lift manifest, but agnostic for other top-level keys, this allows the configured fetch binding to store extra metadata about where the file should be fetched from. This would allow an application like ptex to be written seperate from the scie-jump that could be included in scies to turn them into ptexes - portable thin executables.
Twitter had a use case for this in the context of distributing very large PEXes in their datacenters. If the scie conceptually contained a packed layout PEX, it could be shipped as a ptexed scie that just had the scie-jump and ptex binary blobs inside with all the rest of the application content, up to and including the Python interpreter, provided lazily by ptex on 1st boot.
With the syntax approach sketched out here the config format stays the same - only a new placeholder is introduced; so this idea can be deferred without worry of breaking the format.
The text was updated successfully, but these errors were encountered: