-6

As the title says, I've been noticing this trend that have been all along the evolution of programming languages. Each one has had a niche build tool and a dedicated package/lib repository system.

Its hard for me to ignore that nearly all of them are:

  1. Downloading/uploading archives with certain files and metadata.
  2. Extracting/packing/altering some directory structure as per the programming language conventions.
  3. Calling the compiler or other tools, CLI etc to do work in the defined steps and tasks.

Although some cater to specific conventions of the programming language, but the major part of the same, repeated functionality is hard to miss.

Maven, npm, cargo, gradle, and the list goes on. How could it be not so obvious to see the pattern and how come there are no popular generic solutions or tools for this ? Its it just that programming language creators just don't want to collaborate in this space or there is some historical or technical reason I'm missing ?

In short, why not pack the language specific conventions in a plugin or extension that re-used existing agnostic tools/servers, instead of rolling out one more repository server and one more build tool ?

Note: The question is not about the tools themselves, but the common mechanics involved with "sharing code packages" that are re-invented again and again.

6
  • 2
    Questions which lump all kinds of tools or things together won't work well on this site. I think there is a different history and different motivation behind each of these tools. If you want to know, for example, why the Rust community created their own package manager "cargo" instead of making a plugin for an existing one like npm, then ask one question about cargo. Ideally, you ask this question in a Rust forum, not here, I am voting to close this as "needs more focus".
    – Doc Brown
    Jun 28, 2021 at 11:45
  • ... and who says there are no plugins? Try plugins.gradle.org/search?term=Rust or plugins.gradle.org/search?term=Node
    – Doc Brown
    Jun 28, 2021 at 12:17
  • @DocBrown I could omit explicitly naming the tools, yet the observed pattern is there. Build automation and package management are integral parts of a SDLC that are common, irrespective of the choice of programming language and tools. And the question is about why a common problem (even if partial) does not have any attempts for a common solution, and not about why X programming language uses Y tool. Though I agree this question can be considered asking "reasons for opinions" and you can surely close it if you see fit.
    – S.D.
    Jun 28, 2021 at 12:17
  • 1
    You did not get my point. Omitting the names of any tools would make your question worse, not better. I said you should ask for each tool individually, because you will most probably get for each tool a different answer. However, this SE site is not a good one for asking about the history of design decisions of certain tools - tool related forums are a way better place.
    – Doc Brown
    Jun 28, 2021 at 12:21
  • 2
    I challenge the premise of the question. make is THE build system, and completely language-agnostic. Dpkg/.deb, RPM, are package management systems that have been around forever, and are completely language-agnostic. Jun 28, 2021 at 12:49

1 Answer 1

4

Because package maintenance is one of those tasks that most people think is easy - just administrate a bunch of version numbers and associated binary content - but really, really isn't.

To properly handle packages for a programming language requires deep knowledge about the runtime system and usually the implementation of its standard interpreter - knowledge that only someone deeply embedded in the community of users of that language will have. A tool that tried to install Javascript, Java, Python and Go libraries would almost certainly do all of those jobs worse than the dedicated tools - probably badly enough that people wouldn't want to use it.

11
  • 1
    The question is not about building an all in one tool, but about re-using some of the existing ones with something that requires a lot less work, like a plugin. For example on repository side, just storing and serving a zip archive plus metadata JSON certainly does not require deep understanding of whats in the content of the files, its up to the plugin to make sense of that.
    – S.D.
    Jun 28, 2021 at 10:41
  • @S.D. yes, but that functionality is not complicated to set up. You literally can define a scheme by which all classifying info about an artifact is mangled and you can just host the files. E.g. Maven repositories <tld>/subpath/<groupId>/<artifactId>/<version>/<artifactId>-<version>.<classifier>. Done.
    – marstato
    Jun 28, 2021 at 11:34
  • @KilianForth what knowledge of the implementation are you referring to? How to load different kinds of libraries into the runtime?
    – marstato
    Jun 28, 2021 at 11:37
  • @marstato different languages use different runtimes and toolchains (e.g. compilers/interpreters), and even different runtimes within language ecosystems. For example, .NET has at least 4 different target runtimes (each with multiple versions); C# projects may target any combination of them, so NuGet needs to handle .NET packages differently depending on the target framework(s) for a project, affecting the way that those packages are checked, installed, upgraded, etc. Just a totally different set of problems to be solved compared to something like NPM. Jun 28, 2021 at 11:51
  • 2
    I think the fallacy here is the assumption that different package managers are solving the same problem for different languages when in fact they aren't. Jun 28, 2021 at 11:51

Not the answer you're looking for? Browse other questions tagged or ask your own question.