I think parent wrote that because nowadays many projects are for JavaScript or Python with lots of dependencies.
I've seen embedded C code that requires Python AND Ruby to build.
Linux is still using makefiles (+ config). Your project cannot possibly be more complicated
The Guix project recently hit a massive milestone in untangling this, by creating a package set which starts by building a 357-byte program and works its way up to the utilities you'd expect: https://guix.gnu.org/blog/2023/the-full-source-bootstrap-bui...
I had one embedded project that I handrolled the makefile for, and it was all in pure C, no OS. That was fine, but ensuring that the versions of the hardware abstraction layer, and other drivers I wanted to use from the same vendor was a source of annoyance. Keeping track of which source files were to be enabled and disabled in the makefile was also annoying.
Another project I am working on uses platformio on an RTOS (and a much bigger micro). Platformio is written in Python to handle all of that 'seamlessly' and it does work pretty well from my perspective. And I don't have to manually install separate toolchains to /opt (or wherever) and keep track of them; it 'just works.'
I like the makefile approach. With only a little work, it's possible to make clean build directories without .o files littered around like mouse droppings. I know exactly what code is being built, and, because I usually have to write the linker script, where it is being put. But once it gets more complicated with different toolchains and compatibility problems (and it usually does if you have an RTOS), it sure is nice to have something like Platformio.
So I could go to all the trouble to have a cascading compilation all in pure c or c++, so the git SHA is written into a given source file, which is in turn built and flashed onto my target device. Or I could use an interpreted language for all the off-the-device operations, completely skip over configuring a separate development environment, and do it all in a fraction of the time.
The only reason I want to be compiling c or c++ for the host is because I'm also writing a driver at the same time, and even then...
Just curious, but based on your experience, why does it “usually” get more complicated in those ways with an RTOS?
The `cryptography` library (I'd say quite an important one in the Python ecosystem) requires Python, C and Rust to build, since v3.4.
A full text search for "python" reveals only a single match hidden at the bottom within the FAQs section; ironically within the context "Why are there no wheels for my Python3.x version?".
Most of the other FAQs add to it:
- I cannot suppress the deprecation warning that cryptography emits on import
- cryptography failed to install!
- Why does cryptography require Rust?
- Installing cryptography produces a fatal error: 'openssl/opensslv.h' file not found error
- cryptography raised an InternalError and I’m not sure what to do?
- Installing cryptography with OpenSSL 0.9.8, 1.0.0, 1.0.1, 1.0.2, 1.1.0 fails
- Installing cryptography fails with error: Can not find Rust compiler
- I’m getting errors installing or importing cryptography on AWS Lambda
- Why can’t I import my PEM file? What happened to the backend argument?
- Will you upload wheels for my non-x86 non-ARM64 CPU architecture?
Python is by far the most platform-dependent, brittle programming environment, and the prime example that the "interpreted languages run everywhere!" trope is increasingly dead.
Build nonce, fail everywhere.
I’m pretty sure that was a typo, but it was an excellent one and I hope it doesn’t change! :)
I meant: "Python *has by far the most platform-dependent, brittle programming environment".
> You are choosing to use a c/rust accelerated library.
Especially with something as fundamental as `cryptography`, I don't choose it - it is a given through transitive transitive dependencies.
> If your project were 𝗽𝘂𝗿𝗲 c or rust, you would still have to build everything.
That's the whole point: when developing in programming language XYZ, then stay within XYZ's environment: As much as possible, implement stuff by writing in XYZ, and import other stuff following this principle.
Whereas, the moment you or one of your dependencies delegate to other environments, your program inherits and requires additional environments.
So many projects and libraries in Python World have taken the latter approach, resulting in so many Python applications being a cobbled-together Frankenstein diva. It will refuse to work on your users' system, until they have the correct rubyenv, and autoconf version, and npm.
"Huh, why does the user report a problem with npm when installing my Python application?". Well, that could be because unbeknownst to you, whenever you yourself developed, updated, and ran your program, there was always this tiny dependency of a dependency that needs it - you just didn't know about it until this issue report, because your system already had Node and npm set up correctly. That reporting user's not!
Like, a ton of our ops-scripting, things have 2-3 direct dependencies and maybe 10 transitive dependencies. And the latter is an actual flask application with pydantic, so a bit outside of "scripting". We've settled on a set of these versions, put them into a venv on a system and that's it. Update every few weeks, get accustomed to the libraries. Nice and stable base to work with.
And then we have some of our python-based ML teams. I'm not joking, but I have entire classes of servers which - including their dataset - are smaller in storage footprint than some of their python containers including tensorflow and models and panda and all manner of things. Feel free to accuse me of comparing apples and oranges, but that feels very, very strange.
I come from an embedded systems / microcontroller background though, so the bloat does feel completely insane.
For me things like Django feel "worse" overall in terms of developer QoL than the ML universe does, but maybe just because I don't know it as well and my last real webdev experience was before PHP4/HTML5.
The snark is mostly arising because I recently wrote a little tool to do an inventory of our private docker registry, because storage was getting difficult to manage. After a whole bunch of messy data collection and setup, it sets up a graph of the layers in the registry, assigns images and tags to owners. From there it backpropagates "ownership" of layers - if a layer is only referenced by images attributed to one team, that layer belongs to the team, else it's marked as mixed.
Before doing that, people were enthusiastic about making image builds more efficient, tagging smarter, collecting faster. A great atmosphere I'm finding myself enjoying more and more in the company, which is great.
However, doing the analysis pretty much showed us that 90% - 95% of the storage used in the private registry was used by these python/ml docker images. We found several projects whose CD images were not being garbage collected by the setup for 2 years or so. This wasn't great, but the entirety of their images took up less storage than like 2 base images of the ML stack.
It's the thing we have to do, but I reserve my right to make fun of it.
Of course they did. But they made it sound like the language is the deciding factor, and that's not true.
C can have horrific-to-install dependencies, even worse than you see with binary python packages.
The upside of that copy-and-paste coding is that you don't have dependencies. But I'd hardly call it a virtue.
My entire system is built on a staggering amount of C libraries.
Until recently, literally the only way to have your code reused from different applications in different languages was to use C, or use C++ with the interface butchered to be C compatible.
Other languages code reuse is "well, first you have to go all in into our platform", which is great from the POV of someone already on that platform, but not so great if you just want to reuse a small bit of code from that other language.