4 ms·
Perhaps a non-starter for you if you don't want to involve Docker but I have had good experiences wrapping a docker invocation in a shell script shim with the s
by meddlepal 7y ago
Perhaps a non-starter for you if you don't want to involve Docker but I have had good experiences wrapping a docker invocation in a shell script shim with the same name as the program and forwarding everything I need into the container. Then folks just grab the shell script and they're off... added bonus it's really easy to add update functionality to your tools.
- BerislavLopac 7y agoSo you're replacing a single executable Python script with a dependency that requires four additional separate artefacts (Dockerfile, image, container and the shell script) to be executed...
- Areading314 7y agoAs well as Docker being installed, and configured, which implies admin access to the hardware you're running it on
- meddlepal 7y agoIt's like you conveniently missed the first sentence. 1. Nothing stays a simple as time happens. New shit gets added. 2. Eventually people do want to use libraries so you're back to square 1. 3. It's "cross-platform" runnable now so those annoying macOS and Windows users can suddenly use it. Though depending on how you do the shim it might be tricky. I've taken to writing the shim in Go lately so I can poop out a static binary that does the rest of the work. 4. It's really easy to keep stuff up to date if your users are non-technical... simply have the shim docker pull a new version on startup. To the end user it requires just a single artifact. For the developer there's a bit more stuff to manage but it's not exactly like any of this is hard stuff to figure out.