https://pantsbuild.org/ logo
Join Slack
Powered by
I’ve done some very draft quality code to implemen...
# development
a
I’ve done some very draft quality code to implement runnable dependencies for 
shell_command
and 
adhoc_tool
, which also allows version pinning for pre-installed binaries that themselves need runnable dependencies (e.g. 
yarn
depends on 
node
). Would appreciate some feedback on the API approach here: https://github.com/pantsbuild/pants/pull/18347
As an example, here’s how you can populate a 
node-modules
directory with version-pinned yarn and node:
Copy code
# Dependencies and source files
files(
    name="package-config",
    sources=["package.json", "yarn.lock",],
    dependencies=[],
)

# The source files themselves
files(
    name="js-sources",
    sources=["*.js",],
    dependencies=[],
)

system_binary(
    name="yarn",
    binary_name="yarn",
    fingerprint=r"1\.22\.19",
    fingerprint_args=["--version"],
    fingerprint_dependencies=[_runnable(name="node", address=":node")],
)

system_binary(
    name="node",
    binary_name="node",
    fingerprint=r"v19.0.1",
    fingerprint_args=["--version"],
)

# Fetch the dependencies and produce a `node_modules` directory

adhoc_tool(
    name="node-modules-pinned",
    runnable=":yarn",
    args=["install", "--immutable"],
    dependencies=[":package-config"],
    execution_dependencies=[
        ":package-config", _runnable("node", ":node"),
    ],
    output_directories=["node_modules"],
    timeout=300,
)
c
it seems like a configuration nightmare that you need to provide a `system_binary`’s runnable dependencies everywhere it is used.
a
absolutely.
that would go away if we had dependency scoping, and could track those dependencies transitively.
👍 1
The whole 
adhoc_tool
saga has been an exercise in “if you can’t make things easy, at least make it possible”
and sometimes you end up with crappy results like this one 🙂
4 Views
Open in Slack
PreviousNext
Powered by