DotSlash: Simplified Executable Deployment

(github.com)

Comments

mbreese 20 February 2025
I'm not sure how to feel about this.

On one hand, it's an appealing way to manage dealing with different OS/Arch for a binary. On the other hand, this is not something I'd want to use in production, as it's very implicit. I'd rather explicitly call specific versions of installed binaries over implicitly call files installed in $DOTSLASH_CACHE (particularly if the binary is fetched on-demand).

This looks like it could be a useful tool in certain situations, such as shared/consistent dev environments. But generating the dotslash file (with hashes, urls, etc...) seems quite manual, which will limit adoption. In this way, it's not too different from traditional environmental module files, but it does automate a good chunk. If the main use-case is development, I'm not sure if this is better than devcontainers.

It seems like a useful tool, but I'm not sure where I'd actually use it. Maybe I'm missing the main use cases?

0cf8612b2e1e 20 February 2025
What’s the sell on this vs committing a mise/asdf/etc configuration with pinned versions?
mrbluecoat 20 February 2025
> executing a DotSlash file could "run anything,"

https://dotslash-cli.com/docs/motivation/

Seems promising but obviously security around the dotslash file needs to be well thought out.

umvi 20 February 2025
This seems like it could be a good way to manage multiple toolchains as well (multiple golang, etc)
mhh__ 20 February 2025
Absolutely love this style of tool management. Why do we ever install anything?

Edit: consider also git bisect!

VyseofArcadia 20 February 2025
Not to be confused with Slashdot, the tech and tech-adjacent news aggregator of yore.
mvuksano 20 February 2025
Looks like one more open source project used to show "external impact" for a PSC.