4 ms·

rpm and deb are tied to specific operating system distributions, and are also meant to install packages globally on a system. npm, on the other hand, is meant t

rpm and deb are tied to specific operating system distributions, and are also meant to install packages globally on a system. npm, on the other hand, is meant to be cross-platform and is primarily focused on installing dependencies on a per-project basis. Its rules for lookup, matching, deduplication etc are mostly defined or informed by Node.JS conventions. I don't think apt or rpm would be willing to cover these use cases, and even if they did, it would probably not be worth it

LoSboccacc 8y ago
the maven model has worked quite well so far.
- codefined 8y ago
  I'm not sure if it's a model thing or just that software has bugs, but lots of people really dislike Maven. Not sure it's an example of a good package manager.
  - jrs95 8y ago
    The CLI is among the least intuitive I’ve ever used, and pom.xml is pretty verbose and complex. That being said, it works very well and I’ve never had a problem with it (other than it’s aesthetics) after grokking it.
  - peeters 8y ago
    Do they hate the package management or the build tool? Maven introduced a new package format (the Project Object Model, pom.xml) at the same time as introducing a very declarative build tool. The really confusing part is that the two are conflated by design: if building with Maven, your project's pom.xml also contains the declarative Maven configuration used to build your package, instead of containing just the package metadata (name, dependencies, etc). But that's not required, and it need not be part of the *.pom XML file deployed in the published package. Since release, many build tools have been introduced that can consume and produce POM-compatible packages but don't require you to use Maven itself as your builder (Ivy for Ant, gradle for writing build scripts in Groovy, SBT for Scala, etc).
    - _asummers 8y ago
      Just a note: you can use Gradle for Java too. I haven't built a Java project without Gradle since like 2010 or so.
      - peeters 8y ago
        Yeah sorry if I wasn't clear, in Gradle the build script is written in Groovy. It is used to build any number of project types.
        vorg 8y ago
        Gradle build scripts can also be written in Kotlin.
  - tlarkworthy 8y ago
    I spent yesterday trying to get protobuffers working in maven, see http://vlkan.com/blog/post/2015/11/27/maven-protobuf/ http://vlkan.com/blog/post/2015/11/27/maven-protobuf/ for the pain. Anything counter to maven's way is a PITA. In this case, Maven dislikes platform specific binaries.
- realusername 8y ago
  Technically yes, on the usability part there's still a long way to go...
pmlnr 8y ago
> globally on a system In the world of containers? Come on.
- solatic 8y ago
  You understand that you can install a deb/rpm inside a container, right? The conservation of complexity is at play here. Either you have a quasi-complex deb/rpm, and a simple Dockerfile with a RUN command installing it, or you have a quasi-complex Dockerfile which does all the packaging work itself.
  - pmlnr 8y ago
    > You understand that you can install a deb/rpm inside a container, right? That's exactly why I replied. deb/rpm in container is a reasonable choice, and that way, they aren't global for the system but local in the container.

LoSboccacc 8y ago

the maven model has worked quite well so far.

codefined 8y ago
I'm not sure if it's a model thing or just that software has bugs, but lots of people really dislike Maven. Not sure it's an example of a good package manager.
- jrs95 8y ago
  The CLI is among the least intuitive I’ve ever used, and pom.xml is pretty verbose and complex. That being said, it works very well and I’ve never had a problem with it (other than it’s aesthetics) after grokking it.
- peeters 8y ago
  Do they hate the package management or the build tool? Maven introduced a new package format (the Project Object Model, pom.xml) at the same time as introducing a very declarative build tool. The really confusing part is that the two are conflated by design: if building with Maven, your project's pom.xml also contains the declarative Maven configuration used to build your package, instead of containing just the package metadata (name, dependencies, etc). But that's not required, and it need not be part of the *.pom XML file deployed in the published package. Since release, many build tools have been introduced that can consume and produce POM-compatible packages but don't require you to use Maven itself as your builder (Ivy for Ant, gradle for writing build scripts in Groovy, SBT for Scala, etc).
  - _asummers 8y ago
    Just a note: you can use Gradle for Java too. I haven't built a Java project without Gradle since like 2010 or so.
    - peeters 8y ago
      Yeah sorry if I wasn't clear, in Gradle the build script is written in Groovy. It is used to build any number of project types.
      - vorg 8y ago
        Gradle build scripts can also be written in Kotlin.
- tlarkworthy 8y ago
  I spent yesterday trying to get protobuffers working in maven, see http://vlkan.com/blog/post/2015/11/27/maven-protobuf/ http://vlkan.com/blog/post/2015/11/27/maven-protobuf/ for the pain. Anything counter to maven's way is a PITA. In this case, Maven dislikes platform specific binaries.
realusername 8y ago
Technically yes, on the usability part there's still a long way to go...

pmlnr 8y ago

> globally on a system In the world of containers? Come on.

solatic 8y ago
You understand that you can install a deb/rpm inside a container, right? The conservation of complexity is at play here. Either you have a quasi-complex deb/rpm, and a simple Dockerfile with a RUN command installing it, or you have a quasi-complex Dockerfile which does all the packaging work itself.
- pmlnr 8y ago
  > You understand that you can install a deb/rpm inside a container, right? That's exactly why I replied. deb/rpm in container is a reasonable choice, and that way, they aren't global for the system but local in the container.