Show HN: Avenv – A more isolated virtualenv
I&#x27;d like to say good things, but there are a few big issues first.<p>It goes to the effort of downloading the sha256 hashes... For a filename. It never actually confirms a download is accurate with them. (curl --fail is not enough. You can have connections close nicely, but the file not be transferred correctly.)<p>It depends on bchroot for the heavy lifting, which is a beta product still, though interesting, and your own... And the habit of placing binaries in git do give me some twinges of concern. It would take more time than I have to audit bchroot. I have some concerns about binding &#x2F;tmp and &#x2F;dev the way you do... But a bigger concern is the assumption that &#x2F;bin&#x2F;bash will be available. What if it isn&#x27;t?<p>It copies _my_ resolv.conf into the chroot blindly, despite the fact that many network managers may overwrite this file, and that my computer can move between networks where this may change. It&#x27;d be better to at least symlink the file. Best would be running a network manager.<p>It assumes x86_64. Reasonable-ish, but not always accurate. A Raspberry Pi is just as strong a target. Use uname -m. You&#x27;ll probably hit issues otherwise.<p>Speaking of which, if you feel the need to grab resolv, you probably want hosts as well.<p>avenv-update finds and sorts binaries from a few static locations. It&#x27;d be much better if it could rely on a PATH variable.<p>---<p>As a _first_ chroot manager attempt, it&#x27;s not awful.<p>You set the right failure flags for sh, and handle most of the fail conditions nicely.<p>... But never trust the internet to hand you blindly what you ask for.<p>... And never trust the assumptions you&#x27;ve made about what it&#x27;s running on will also be accurate.