im not an expert but i think you can just do the first-order dependencies on requirements.txt and then do a pip freeze with constraints.txt and do `pip install -r requirements.txt -c constraints.txt`. that'll make you both happy.
Before constraints.txt came into play, I would've done what you said with pip freeze. With only first-order dependencies, that sounds more likely to break at some point due to the other potential version changes. I think your colleague needs to explain why things are breaking in his case.
* Virtual VM's don't solve my problem everytime. There's software that still requires x86 and a VM isn't going to solve that problem in a few cases. I wish I could get into more details here but I'm kind of a noob in this realm. (TLDR: I need to use something called UAExpert and to resolve this, I have both a separate Linux machine and Windows machine in case I need it)
* Have to install homebrew and an x864 version of homebrew to run the right software. Homebrew does not document this so this solution was based off stack overflow posts.
* While docker states that it supports multiple architectures, I don't find that to be fully true. For our codebase, I need to push up x86 docker images but accidentally pushed up arm64 ones instead. There's a solution for it but it's definitely not an out-of-the-box solution at the moment.
Overall, still pretty happy with it. My older macbook pro had gotten sluggish so the tradeoff for me was worth it.
I stopped playing because I spent most of my time running around the map while being stuck with certain problems. If there was a speed-up button then I would've kept trying.
> I think this means that you're a balanced person
Paradox and balance, I've never thought about it that way before! This is a really huge potential reframe for me. And maybe why I felt so unsettled and anxious, because I was so averse to this paradox as if it's an intrinsically bad thing. Thank you for that!
> They're not arguing that testing or staging environments are bad, they're just saying their organization couldn't manage to get them working.
That is exactly what I got from reading this article. Their staging process was poorly set up and they simply abandoned ship. Additionally, I was getting poor software culture vibes.
Indeed, I found the "We only merge code that is ready to go live" part odd. It seems unrelated to the presence of absence of a staging environment. Where I work, we use staging and also only merge code that is ready to go live.
Similarly, "Poor ownership of changes" and "People mistakenly let process replace accountability" just don't seem staging-related to me. I've been in environments where people throw code over the fence straight into production.
The way I read that is, if you have a staging environment, it is someone else's job to test things before they deploy (Product Manager etc.) which allows them to merge it and forget it. I agree if it is the dev's job then it wouldn't make sense.
The other issue that is fair is the potential lag between dev and production if you have a gate at staging. This way, a developer is likely to move onto something else instead of watching their baby swim into production with all the errors that could cause!
I actually empathize with the statements in the article about the challenges of managing a staging environment. For a lot of systems I worked on, short of just copying customer data into the staging environment (which, depending on your industry or the contracts with your customers may be a big no-no, and the more-distributed your system, the harder that also was to do) it was extremely hard to populate the staging environment with representative data. Or representative state in third-party systems.
(Not to say that testing on a developer's machine wouldn't have these same problems, of course, which I also find the article glosses over.)
