I think people are missing the main point. The real issue with Rust is that it is a designed language which is really tuned and optimized for a specific use case. And for that specific usage, it is really, really good. But even so, it requires a lot more up-front work, due to the limitations and restrictions it imposes.
But it is NOT a good general purpose language. And, maybe to be putting words into the author's mouth, that is their main beef. That every seems to be pushing "Rust All Things" even when it makes no sense, and even if there are much better alternatives available.
So for such comments as "so what about compile time", the issue is that for some, compile time _is a concern_. If it isn't for you, great. But you just can't discount what are valid concerns for others.
People seem to forget that languages are _tools_, and as such, have different sweet-spot use-cases.
This has the same issue as so many package managers for Python, namely, it doesn't provide a way for --no-binary to remain sticky.
There are times when you do NOT want the wheel version to be installed (which is what --no-binary implements in pip), but so many package managers including uv don't provide that core, basic functionality. At least for those that do use pip behind the scenes, like pipenv, one can still use the PIP_NO_BINARY environment variable to ensure this.
It helps, that's for sure. But this sort of knowledge should not exist in the environment in any case. It should be part of the canonical package list, and not hidden away elsewhere. The whole idea of a dependency manager should be a centralized and consistent way to install everything you need and not be dependent on what values may or may not exist as a env-var.
Can you elaborate on the reasons why a package would need to declare that its dependencies must be installed from source rather than from pre-built binaries? I'm having trouble imagining a scenario where that capability would be used as anything other than a workaround for a deeper problem with how your dependencies are packaged.
Let's say you're developing a python package that relies on a native shared library. If you distribute it as a pre-compiled wheel, you're locking your users into the exact version and compilation flags, options, etc that you choose. So your question effectively boils down to "why do people need to compile their own software?".
Many reasons: you need more control, specialized hardware, testing newer versions of the library, maintaining an internal fork of a library, security, performance, the dev team maintains both the native library and python package and needs to keep them independent, or simply preference for dynamic linking against system libraries to avoid duplication.
> So your question effectively boils down to "why do people need to compile their own software?".
No, the question is why a package would need to decide for its users that the package and its dependencies must be installed the gentoo way. That's quite obviously different from why an end user would decide to install from source despite the availability of binary packages.
There are some wheels, for example, 'lxml' that bundle in their binary possibly incompatible external libraries, or older libraries than what you would like. This can cause library conflicts.
It cannot be stressed enough how _vital_ these scripts were to making the WWW an actual functional technical resource; These scripts were a key, if not the key, in growing the actual interactive web, showing the potential of CGI, and in guiding the evolution of web2.0 and beyond.
Its value and place in history can't be overstated.
"You should never worry about betraying your workplace because given the chance, your workplace will definitely betray you. Loyalty to individuals. Relationships. That's what makes the world go round."
But it is that exact kind of unknown which makes most people and entities avoid those licenses in the 1st place. If the goal is to significantly limit the distribution and reach, I guess it makes sense, but if the goal is to have people actually use it (and therefore hopefully contribute to it), then those licenses and the projects that use them are actively avoided.
The entire work can be licensed under GPL, but those parts that were MIT remain, individually, still under MIT. MIT specifically and explicitly allows for 'sublicense'ing
Correct. And the combined work needs to carry the MIT license text and copyright attributions for the MIT software authors. With binary distribution it must also be overt, not hidden in some source code drop, but directly accompanying the binary.
Many people who talk about relicensing never credit the MIT developers or distribute the MIT license text. "Because it's GPL now."
I don't think that you believe that, but many developers do.
Some don't see the need for source code scans for Open Source compliance, because the license.txt says GPL, so it's GPL. Prime example is the Linux kernel. There is code under different licenses in there, but people don't even read https://github.com/torvalds/linux/blob/master/COPYING till the end ("In addition, other licenses may also apply.") and conclude it's simply GPL 2 and nothing else.
Also be aware that sublicensing is not the same as relicensing.
