Hacker News new | comments | ask | show | jobs | submit login

Your 2) is spot on - I think its the major reason we build up this cruft. By making an explicit choice to add something to my docker file I have decided it is worth the 2 minutes mental effort (for me a surprisingly high bar!)

not sure I get 5/6 - will dive in later (just decided this project needs a roadmap)






5/6 is the distinction between:

apt get update && apt get upgrade

vs:

curl https://rust-lang.com | grep "new version" && curl "https://rust-lang.com/installer.sh" | sh

I have very high confidence that debian/apt is "immutably available and consistently managed", but many of the non-free pieces of software (corporate-source or "not yet standardized, maintained, and included in debian") can/could require special attention, especially regarding updates.

build-env.sh - the operating system, apt-only, "just a linux box", download and install the heroku tooling b/c I often need it, but it's not in the main debian package pool.

bake-env.sh - "geeze I hate waiting for heroku, rust, and random vim plugins to download... let me freeze this moment in time" ... apt-get update still works and will keep O.S. up to date, but heroku, rust, vim plugins, etc won't "auto-install / auto-update" b/c they don't have properly managed versions or an install/update cycle like the rest of the o.s.


the bake-env.sh seems to just trigger a flag in the Dockerfile

So you have a set of dotfiles, on your url, and if bake-env, those are part of the docker build - and presumably the dotfiles do the rust installs etc, so your docker is ready with rust ecosystem installed (not a rust user so unclear) and then you can happily ignore it till you need to upgrade some rust package ?




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: