4 ms·

Back in the day we had curated libraries. E.g. Roguewave, Boost, etc. You chose your libraries relevant to domain needs and stuck with them. Adding a new librar

Back in the day we had curated libraries. E.g. Roguewave, Boost, etc. You chose your libraries relevant to domain needs and stuck with them. Adding a new library to the project was a big deal. This may still be true in C & C++ land, and to small extent in the Java world with the Spring libraries. But Node, Python, et al. seem to have zero curation and an explosion of transitive dependencies. By making it easy to reference arbitrary dependencies, projects haul in random unscrutinised dependencies.

stevekemp 7y ago
Off-topic, but reading "Rogeuwave" gave me a sudden flashback to an old project. Genuinely a name I've not heard for 20+ years. Thanks for the memories!
- scriptdevil 7y ago
  Their c++ stdlib docs used to be best in class around 2008... Maybe even later
weinzierl 7y ago
> But Node, Python, et al. seem to have zero curation and an explosion of transitive dependencies. By making it easy to reference arbitrary dependencies, projects haul in random unscrutinised dependencies. Adding a library should be easy and I think we shouldn't blame ease of use. I'm worried too about the explosion of dependencies in Node, Python and Rust in my case specifically, but at the same time I'm happy that I don't have to waste my time with the boring work of adding a new library like in C or C++. What is needed in my opinion is three things: 1. Developers should be more suspicious. I believe security disasters to come will solve this problem over time. 2. A better way to express trust in package managers. I would like to be able to express trust or revoke trust against persons and groups and not against packages. For example in the Rust world there are a view packages written by folks that mainly write the standard library and work on the compiler. I trust these people and if I wouldn't I probably couldn't use Rust at all. So I don't want to spend a single thought about importing one of these crates. Crates form others will undergo more scrutiny, but ultimately using a package or not boils down to the fact that I trust certain people and per default I don't trust everyone else. What I want to be able to do is to express to my package manager, so it prevents me from using stuff from untrusted entities and at the same time doesn't bother me otherwise. 3. Curated repos. When I wrote Java for big corp we had to use a curated Maven repo. The regular public Maven repo was not allowed. The curated version was supplied by a third party, Sonatype in this case. Back then I thought this service will become a big deal, that we will soon have many companies that provide services like Sonatype and that they will blossom. It never happened but maybe time was not ripe for it...
rumanator 7y ago
> This may still be true in C & C++ land, and to small extent in the Java world with the Spring libraries. But Node, Python, et al. seem to have zero curation and an explosion of transitive dependencies. That's a great point. I wonder if there is any interest in providing a Boost-esque package bundle for Node or Python, where maintainers adopt a selection of packages and treat their official releases as unstable/bleeding edge releases.
detaro 7y ago
Don't really agree about Python. The trend is still to larger projects maintaining a set of libraries that are relatively self-contained.

stevekemp 7y ago

Off-topic, but reading "Rogeuwave" gave me a sudden flashback to an old project. Genuinely a name I've not heard for 20+ years. Thanks for the memories!

scriptdevil 7y ago
Their c++ stdlib docs used to be best in class around 2008... Maybe even later

weinzierl 7y ago

> But Node, Python, et al. seem to have zero curation and an explosion of transitive dependencies. By making it easy to reference arbitrary dependencies, projects haul in random unscrutinised dependencies. Adding a library should be easy and I think we shouldn't blame ease of use. I'm worried too about the explosion of dependencies in Node, Python and Rust in my case specifically, but at the same time I'm happy that I don't have to waste my time with the boring work of adding a new library like in C or C++. What is needed in my opinion is three things: 1. Developers should be more suspicious. I believe security disasters to come will solve this problem over time. 2. A better way to express trust in package managers. I would like to be able to express trust or revoke trust against persons and groups and not against packages. For example in the Rust world there are a view packages written by folks that mainly write the standard library and work on the compiler. I trust these people and if I wouldn't I probably couldn't use Rust at all. So I don't want to spend a single thought about importing one of these crates. Crates form others will undergo more scrutiny, but ultimately using a package or not boils down to the fact that I trust certain people and per default I don't trust everyone else. What I want to be able to do is to express to my package manager, so it prevents me from using stuff from untrusted entities and at the same time doesn't bother me otherwise. 3. Curated repos. When I wrote Java for big corp we had to use a curated Maven repo. The regular public Maven repo was not allowed. The curated version was supplied by a third party, Sonatype in this case. Back then I thought this service will become a big deal, that we will soon have many companies that provide services like Sonatype and that they will blossom. It never happened but maybe time was not ripe for it...

rumanator 7y ago

> This may still be true in C & C++ land, and to small extent in the Java world with the Spring libraries. But Node, Python, et al. seem to have zero curation and an explosion of transitive dependencies. That's a great point. I wonder if there is any interest in providing a Boost-esque package bundle for Node or Python, where maintainers adopt a selection of packages and treat their official releases as unstable/bleeding edge releases.

detaro 7y ago

Don't really agree about Python. The trend is still to larger projects maintaining a set of libraries that are relatively self-contained.