4 ms·

Personally I believe that vendoring is just the lazy approach by developers that do not want to care about the eco system their software runs in. Consequently,

Personally I believe that vendoring is just the lazy approach by developers that do not want to care about the eco system their software runs in. Consequently, their software will probably not be maintained for a long time (Red Hat offers 10 years of support, for instance). It's a shame but it seems like the cool kids simply tend to ignore sustainability in software development. Since npm,pip,go,cargo, etc. are open source projects, would it not be simpler to add a "debian mode" to them? In that mode, the tool could collaborate with the system package manager and follow any policies the distribution might have.

zozbot234 6y ago
> Personally I believe that vendoring is just the lazy approach by developers that do not want to care about the eco system their software runs in. I have to agree. If your dependency is used by more than one package within the distribution, it should be split out and not vendored - ultimately, this will reduce the total workload on package maintainers. This however does not mean that distros should be splitting every dependency into a separate package by default, much less have a separate package in the archive for each build configuration - there's no need to litter the distribution repo with idiosyncratic packages that will never have more than a single project/app/library depending on them, and that's precisely where a vendoring/bundling focused approach might be appropriate. Such dependencies are more like individual source-level or object files, that have always been "bundled" as part of a self-contained application.
- Blikkentrekker 6y ago
  The problem is that in the real world despite promises of semantic versioning, breaking often occurs which makes it impossible for two packages to depend on the same version of another library though in theory they should.
  - ernesth 6y ago
    Debian used to manage and package programs from the real world. It is obviously easier to create breaking changes that will not be discovered in dynamic languages. But in the real world, where everybody do unit tests, it is difficult to understand what kind of new problems were not already encountered 20 years ago.
    - Blikkentrekker 6y ago
      Well Rust and npm happened in that time. I don't have much experience with the latter but I know of the former that despite promises of semantic versioning, it is quite common for a crate to not work with a newer version, requiring one to hard depend on a specific version. Add to that that Rust's definition of “non-breaking change” in theory can include changes that A) read to compilation errors or B) compile fine but lead to different behavior.
- m000 6y ago
  > If your dependency is used by more than one package within the distribution, it should be split out and not vendored... That's like going back to square-one: Dependency Hell [1]. That's a regression, not a solution. I believe the problem is not at the edges (OS packaging, software developers), but in the middle: The dependency handling in programming languages. I.e. you need to be allowed to install multiple versions of a library under the same "environment" and activate the version you want at launch time (interpreted languages) or build time (compiled languages). [1] https://en.wikipedia.org/wiki/Dependency_hell https://en.wikipedia.org/wiki/Dependency_hell
  - zozbot234 6y ago
    Dependency hell is a result of not using sensible semantic versioning. If libraries are properly versioned, it's easy to make sure that each dependency uses the latest compatible version.
floatboth 6y ago
With scripting runtimes like ruby and python, it's already kind of "Debian mode", with a system-wide location for packages. With compiled languages that really prefer to statically link stuff written in that language (rust, go, etc) it's really not feasible. In FreeBSD Ports we have a very pleasant solution for packaging rust apps. You just run `make cargo-crates` and paste the output into the makefile – boom, all cargo dependencies are now distfiles for the package.
deleted 6y ago
[deleted]
wizzwizz4 6y ago
Cargo already has one: https://crates.io/crates/cargo-deb https://crates.io/crates/cargo-deb
macksd 6y ago
It's not like there's one ecosystem your software runs in. Sure, they could add a Debian mode. But you'd also need a Red Hat mode, Apple mode (and I don't know - do you need a homebrew mode that's different from the default mode?), Windows mode, etc. I think it's equally fair to say that the ecosystems just haven't solved the dependency management problem flexibly enough for everyone. Not everyone needs to or wants to support things for 10 years in order to have a Red Hat mode unless Red Hat is picking up that burden for them or paying them.
npsimons 6y ago
> Personally I believe that vendoring is just the lazy approach by developers that do not want to care about the eco system their software runs in. As someone with a foot in both worlds, allow me to try to put it more diplomatically: developers' job is to get into the weeds, pay attention to tiny little details, and know every piece of their code so well they often visualize the problem and fix in their head before even putting hands to keyboard. They don't want to have to deal with "other peoples' software." System administrators (and by extension, distribution maintainers) have to take in the bigger picture: how will this affect stability? Resources? How will this package interact with other pieces of software? They have to consider use cases in everything from the embedded to insanely large clusters and clouds. It would behoove developers to try to expand their awareness of how their software fits in with the rest of the world, if even for a short while. It's hard (I know), but in the end it will make you a better developer, and make your software better. > Since npm,pip,go,cargo, etc. are open source projects, would it not be simpler to add a "debian mode" to them? This is the best fucking idea I've heard in a while!

zozbot234 6y ago

> Personally I believe that vendoring is just the lazy approach by developers that do not want to care about the eco system their software runs in. I have to agree. If your dependency is used by more than one package within the distribution, it should be split out and not vendored - ultimately, this will reduce the total workload on package maintainers. This however does not mean that distros should be splitting every dependency into a separate package by default, much less have a separate package in the archive for each build configuration - there's no need to litter the distribution repo with idiosyncratic packages that will never have more than a single project/app/library depending on them, and that's precisely where a vendoring/bundling focused approach might be appropriate. Such dependencies are more like individual source-level or object files, that have always been "bundled" as part of a self-contained application.

Blikkentrekker 6y ago
The problem is that in the real world despite promises of semantic versioning, breaking often occurs which makes it impossible for two packages to depend on the same version of another library though in theory they should.
- ernesth 6y ago
  Debian used to manage and package programs from the real world. It is obviously easier to create breaking changes that will not be discovered in dynamic languages. But in the real world, where everybody do unit tests, it is difficult to understand what kind of new problems were not already encountered 20 years ago.
  - Blikkentrekker 6y ago
    Well Rust and npm happened in that time. I don't have much experience with the latter but I know of the former that despite promises of semantic versioning, it is quite common for a crate to not work with a newer version, requiring one to hard depend on a specific version. Add to that that Rust's definition of “non-breaking change” in theory can include changes that A) read to compilation errors or B) compile fine but lead to different behavior.
m000 6y ago
> If your dependency is used by more than one package within the distribution, it should be split out and not vendored... That's like going back to square-one: Dependency Hell [1]. That's a regression, not a solution. I believe the problem is not at the edges (OS packaging, software developers), but in the middle: The dependency handling in programming languages. I.e. you need to be allowed to install multiple versions of a library under the same "environment" and activate the version you want at launch time (interpreted languages) or build time (compiled languages). [1] https://en.wikipedia.org/wiki/Dependency_hell https://en.wikipedia.org/wiki/Dependency_hell
- zozbot234 6y ago
  Dependency hell is a result of not using sensible semantic versioning. If libraries are properly versioned, it's easy to make sure that each dependency uses the latest compatible version.

floatboth 6y ago

With scripting runtimes like ruby and python, it's already kind of "Debian mode", with a system-wide location for packages. With compiled languages that really prefer to statically link stuff written in that language (rust, go, etc) it's really not feasible. In FreeBSD Ports we have a very pleasant solution for packaging rust apps. You just run `make cargo-crates` and paste the output into the makefile – boom, all cargo dependencies are now distfiles for the package.

deleted 6y ago

[deleted]

wizzwizz4 6y ago

Cargo already has one: https://crates.io/crates/cargo-deb https://crates.io/crates/cargo-deb

macksd 6y ago

It's not like there's one ecosystem your software runs in. Sure, they could add a Debian mode. But you'd also need a Red Hat mode, Apple mode (and I don't know - do you need a homebrew mode that's different from the default mode?), Windows mode, etc. I think it's equally fair to say that the ecosystems just haven't solved the dependency management problem flexibly enough for everyone. Not everyone needs to or wants to support things for 10 years in order to have a Red Hat mode unless Red Hat is picking up that burden for them or paying them.

npsimons 6y ago

> Personally I believe that vendoring is just the lazy approach by developers that do not want to care about the eco system their software runs in. As someone with a foot in both worlds, allow me to try to put it more diplomatically: developers' job is to get into the weeds, pay attention to tiny little details, and know every piece of their code so well they often visualize the problem and fix in their head before even putting hands to keyboard. They don't want to have to deal with "other peoples' software." System administrators (and by extension, distribution maintainers) have to take in the bigger picture: how will this affect stability? Resources? How will this package interact with other pieces of software? They have to consider use cases in everything from the embedded to insanely large clusters and clouds. It would behoove developers to try to expand their awareness of how their software fits in with the rest of the world, if even for a short while. It's hard (I know), but in the end it will make you a better developer, and make your software better. > Since npm,pip,go,cargo, etc. are open source projects, would it not be simpler to add a "debian mode" to them? This is the best fucking idea I've heard in a while!