One problem in the world today is that if you take a widely used program and add a warning to it in some situation, people get mad at you. No matter how useful the warning is, how insidious the situation it protects you against. The reason for this seems to be that not everyone who sees a warning is empowered to fix the underlying cause. You might use a library that does something warning-worthy. You can't change the library yourself to fix the warning. Question for live-program enthusiasts like @Jack Rusher[1][2]: I wonder how much this problem is caused by overusing batch-programming and an insufficiently expressive communication channel for warnings. I made up a wishlist at https://lobste.rs/s/vgnnjt/we_are_stuck_with_egrep_fgrep_unless_you#c_gqhemo that might be interesting to think about together. On the other hand, I see Common Lisp people get annoyed about similar issues: https://mailman.common-lisp.net/pipermail/asdf-devel/2022-January/006680.html [1] https://futureofcoding.slack.com/archives/CCL5VVBAN/p1665503282267399 [2] https://futureofcoding.slack.com/archives/C03RR0W5DGC/p1665594315849469

Not sure this is an issue of live vs. batch. It's more an issue of dependency handling in the Open Source world. In the world of artisanal and industrial products, clients deal with a single supplier, who is responsible for the product sold, including all its components from the supply chain. Commercial software works much like that as well. In Open Source, everybody is responsible for their piece of code but not for its dependencies. In theory, it's the end user who installs everything who is responsible for the correct working of the assembly, but the typical end user can't really do much about technical problems. Ultimately, it's the ambiguous self-image that Open Source developers (both individuals and communities) have. They want to be part of a network of like-minded developers who share code, but they also want large-scale adoption by end users. They end up advertising their products to end users while at the same time proclaiming in the small print not to be responsible for any problems. That's a mismatch between advertising and hard promises that's not so different from commercial vendors.

At a very abstract level, I want to say: the problem is that this is a build time warning expressed as a runtime warning.

Exactly. But the point of live program folks seems to be that we should care about such distinctions less ...

I... mostly don't care about extra warnings? Also, agree with @Konrad Hinsen that this looks like a deps thing, not a live/batch thing.

@Justin Blank Yes, exactly. But technology follows incentives. If someone (person or institution) profits (making money, not being sued) from a software assembly working fine for end users, then that someone will create the tools to deal with potential runtime warnings at build time.

@Konrad Hinsen I don’t agree that OSS developers aren’t responsible for their programs’ dependencies. They may not care about such responsibility, but then they’re irresponsible (and are making low-quality software). What is a true end-user’s problem is assembling independent programs into one they need, and that’s where the real hard-to-resolve impedances kick in (the OSS developers don’t have much incentive to cooperate, unless their userbases overlap totally; end-users usually don’t have the specialty to harmonize the programs). Note that these aren’t problems with dependencies, as the constituent programs can (and are meant to) function independently.

@Jan Ruzicka Assembling software is an issue both for library dependencies and for "independent program" dependencies. In fact, there is little difference between the two other than the interface technology (linking vs. process calls). In both cases, the issue is not bad will nor incompetence, but insufficiencies in both the social structures and the technical infrastructure for software development. The only way an OSS developer can take full responsibility for dependencies is by maintaining forks of everything, and that's beyond most developers' means (but I suspect that this is what Microsoft etc. do).

@Konrad Hinsen When some software has an explicit dependency, then surely the developer uses it consciously (of course, it often gets impractical for some transitive dependencies burrowed under many others). Now, assuming that such a dependency is used only by that one program (it's properly isolated, not being a shared library), then any defect should only come from the dependency itself or from the interaction between the dependency and the program. In the former case, the programmer should have chosen something that works; in the latter, it's probably his fault it doesn't work (unless it's a bug, in which case he unfortunately has to work around it). Yes, I know that in some environments, even isolated dependencies might clash (I've seen this happen with npm packages), but then, why bother using such environments?

@Jan Ruzicka The main issue in practice is dependencies evolving, breaking compatibility intentionally or through bugs creeping in. An example from my own past: in the 1990s, I was part of the team that launched the Scientific Python ecosystem. Our main sustainability worry was "what if Guido is hit by a bus?" We had doubts about Python's survival chance for lack of community support. That turned out to be no issue: Python became immensely popular in the 2000s and developed a large developer community. But then... Python 3 came along, and the Python developer community ended up actively killing Python 2. Lots of domain-specific scientific libraries (including one of my own: https://github.com/khinsen/MMTK/) have become very hard to use because of everyone dropping support for Python 2. And we typically don't have the means for a porting effort to Python 3. So were we negligent in the 1990s for adopting Python 2 as a dependency?

I see. Developing libraries is a risk in this regard (your userbase isn't really "your"). I had standalone "binaries" in mind (usually some pipeline utilities, but also more robust programs). These then depend only on the OS (or the shell).

Exactly. I have wondering for a while to what degree the success of Go is due to its build system encouraging dependency-free binaries. I don't care much about Go as a language, but I noticed that several of the most robust infrastructure software I depend on are written in Go: syncthing, go-ipfs (recently renamed kubo), rclone, gitea, perhaps more.