I think you have got to be meme’ing. You literally wrote 7 paragraphs about how to build something for python when for other languages it’s literally a single command. For Ruby, it’s literally bundle
. Nothing else. Doesn’t matter if it’s got C packages or not. Doesn’t matter if it’s windows or not. Doesn’t matter if you have a different project one folder over that uses an older gem or not. Doesn’t matter if it’s 15 years old or not. One command.
Just for comparison for gradle it’s ./gradlew build
For maven is mvn install
For Elixir it’s mix deps.get
mix compile
For node it’s npm install
every other language it’s hardly more than 1 command.
Python is the only language that thinks that it’s even slightly acceptable to have virtual environments when it was universally decided upon decades ago to be a tremendously bad idea. Just like node_modules which also was known to be a bad idea before npm decided to try it out again, only for it to be proven to be a bad idea right off the bat. And all the other python build tools have agreed that virtual envs are bad.
and yet that all works fine in Ruby, which came out around the same time as Python and yet has had Bundler for 15 years now.
Python - 15+ package managers and build tools Ruby - 1
the closest language to look at for packaging is probably lua, which has similar issues. however since lua is usually not a standalone application platform it’s not a big deal there.
no the closest language is literally Ruby, it’s almost the exact same language, except the tooling isn’t insane and it came out only a few years after python.
You have been in lala land for too long. That list of things to do is insane. Venv is possibly one of the worst solutions around, but many Python devs are incapable of seeing how bad it is. Just for comparison, so you can understand, in Ruby literally everything you did is covered by one command bundle
. On every system.
There’s a good document from the SWAG reverse proxy that explains it all. I reverse proxy everything on my unraid server through swag and have for years.
Just as many issues as not reading the article.
The article says this isn’t to affect existing code.
What problem does this solve that test containers does not? Besides socket access?
They literally told you how it’s used for practical applications and you just ignored it. It makes cryptography stronger, hence your password less likely to be broken. National secrets less likely to be leaked. Your identity less likely to be stolen.
No first time ever. This isn’t a supercomputer, it’s a distributed cloud network that they’re referring to as a supercomputer because it has a lot of power. It’s not a supercomputer in any other sense of the word, as it’s set up on cloud providers around the globe rather than in one location in the same room.
Hey’s spam filtering is a thousand times better than Gmail at least nowadays. Mostly because hey is literally built on the premise that you whitelist who you want to get emails from. The rest are blackholed. But the spam filtering is still very good for the approval part of it.
transpiling is just a type of compiling. compiling in no terms means ‘directly to machine code’.
That’s not the case at all, though it’s very often believed to be and stated as such on here and Reddit.
You’re talking about during CI. Not during the actual coding process. You’re not signing code while you’re debugging.
you don’t code sign during development…
The stats disagree with you, so your anecdotes don’t really mean anything…
You also need to know what the internal GitHub event json looks like. Using act was such a pain I just gave up. Have tried several times now and it’s just easier to create a second repo just for testing and overwrite it with your current repo anytime you need to do major workflow changes.