Lua and Python

Language-specific package managers greatly reduce the friction caused by importing third-party libraries. People like to make fun of JavaScript for using libraries containing a few dozen lines of code (that have comprehensive unit tests, non-obvious patches contributed for surprising edge cases, and lots of real-world testing) but this would be utterly impossible in a world where you had to wait for your library to get packaged by Red Hat and Debian, then wait again for Ubuntu to pick it up, and then wait a few years for that package to become available in the stable releases of all three distributions. Low-friction third party library ecosystems are a huge boost for developer productivity.

Also bad third party libraries can fall out of use, bad standard libraries are forever. Standard library code is also subject to the release cycles of its language runtime.

I think you're missing some of the issues. Let's say that Lua decides to use pip. Does the Python developers want to deal with all the minor issues that Lua is going to need? If no, then you're forking pip anyway, which cuts down on the value of using pip. Either way, now you're using pip; but at the head of this argument is someone not interested in bothering to compile stuff on Windows. I don't want to mess with loading an interpreter on Windows and hoping everything automagically works. They're not using the Linux Subsystem for Windows. Even on Linux, there's always cases with version incompatibility between programs. If you write a program for Lua in Lua, you can usually assume that developers using version X of Lua are happy with the version of the package manager that goes along with version X of Lua. In a world with just Linux, I think things would look a lot of different. But Windows just doesn't have a usable package system for stuff like this, and yet is likely to be the operating system of a fair number of developers.

So, yes, it seems inevitable that a package manager for Lua on Linux, Mac and Windows is going to be written in Lua.

> None have been created by whoever conceived the respective language.

I meant they're developed by people within the community around that language, not necessarily the specific people who designed the language itself. pip is written in Python, npm is written in JS, gem in Ruby, Maven in Java, Cargo in Rust.

If you're part of the Lua community and are willing to put in the effort to solve package management, it's probably because you love Lua more than any other language. You wouldn't want to extend e.g. pip to support Lua packages, because then you'd be spending the next several years writing code in Python and you'd much rather be writing Lua.

>> [..] and because you don't want your language to be weighed down by a dependency on someone else's language [..]
> However, if that reason sticks it is just another instance of the not-invented-here syndrome which forcing upon users and developers alike is not productive.

I don't think that's NIH: there are real practical costs to having dependencies. I can go to https://www.python.org/downloads/ and download an installer for Windows that includes a fully-functional pip. But if pip was written in e.g. Perl, either the Python installer would have to tell me to go and download a Perl installer first, or else the Python installer would have to include a bundled copy of Perl (which would make the download much larger, and would likely introduce many bugs since Python people aren't experts in how to install Perl). It's much more convenient to minimise dependencies and keep everything in the same language.

(That's partly a consequence of Windows not having a distro package manager that could trivially download Perl as a dependency of Python. But Python can't solve that problem, they have to just work around it.)

> This is somewhat self-referential, no? There are too many PMs, so let's invent another one - just for us!

Yes, I think it's a kind of tragedy of the commons. Each language develops a package manager to serve its own interests, while the proliferation of language-specific package managers harms the wider community. That is unfortunate but it also seems inevitable, especially in volunteer-driven communities where self-interest is the primary motivation for most work.

As a member of the wider community, it's more effective to just nudge them towards a slightly better direction, than to insist they do something completely different which (based on experience of every other language that was once in the same situation) has no chance of happening.

> Regarding the non-distribution-like OS(-fragments), there is the question how many of the target audience ("developers"?) actually use just that fragment without anything resembling a PM on that OS, e.g. homebrew, cygwin or the distribution-encompassing Windows Subsystem for Linux.

pypistats suggests Windows accounts for 10% of some packages (e.g. opencv-python) and 4% of other packages (e.g. scipy), while Darwin is around 2%-4%. (WSL is presumably counted as Linux, and I hope nobody is still using Cygwin nowadays.)

That's somewhat less than I expected, but still seems large enough that a language shouldn't disregard those developers entirely.

WSL is great but has some limitations, e.g. you can't use matplotlib.pyplot.show() to get a nice interactive view of your graph except by faffing around with X forwarding over SSH (which isn't an optimal experience). I don't know if you could develop a game using OpenGL in WSL (apparently X forwarding supports that but I'm not sure about performance or features), but I'm pretty sure you couldn't develop a game with Vulkan. Sometimes developers do need native platform support, so a language shouldn't rely entirely on WSL.