Multi account containers + Temporary Containers [1] + I don't care about cookies [2] are an awesome combination I use, I have ~10 fixed containers and for almost everything it's a new container that lives as long as the tab is open.
there are a couple of issues with "moving on", since the project is owned by pypa, it feels it should be the default for python projects, pipenv has a good idea, but in my opinion, a flawed implementation, and maybe all my issues are already resolved in those 600+ commits without release.
About the framing of the question, I think it's because of all the flame wars in the past when people criticized pipenv and maintainers took it a bit personal.
I think the main issue is that you state something that's not true, https://github.com/antirez/redis-doc/pull/984 shows that, Redis Labs is claiming license is OSI-approved, when it's not.
I owned a company that provided off-shore services to companies in the US, it worked perfectly.
If you are doing off-shoring, you really need to insist on the independence and the ability to speak up of the team, it doesn't work if you get yes-men, sadly that's the general case for India-based offshore companies
this is not entirely true, xmonad's config file happens to be a haskell file, but I don't need to recompile the whole xmonad project if I want to change it, I just start xmonad again.
It does some tricks to do this (mainly the _main_ xmonad executable compiles a custom binary for you taking the xmonad.hs as input), but it's a different case.
I've been using Gitlab CI for more than two months now, and it's incredibly simple to set up and really powerful specially with the integration with docker, also, self-hosted gitlab is free.
I also have Teamcity where I work and the comparison is not even fair, I set up gitlab in one day to serve as a continuous integration/deployment server
The main difference is that Django does not rely on monkeypatching or magic methods, and for me the separation of concerns feels just natural in Django.
When I started with Rails it felt like magic, you didn't know why things worked.
"At my current company, we hire based on provable real-world experience."
That is also a pretty bad hiring schema, you are leaving out a great deal of potential great programmers that are just starting, so, which strategy is better? I guess you always leave people behind, if it works for you, it's the right choice, and it has been working for facebook.