Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A critique of package managers

gingerbill.org

Post reply on HN
Print view View original

81–90 of 220 posts

Re: A critique of package managers

#81

Post by alexvitkov »

seba_dos1 wrote: post #68
alexvitkov wrote: post #63

Earlier quoted context omitted.

> If I am providing (lets say) a library that provides some high level features for a car ADAS system on top of a CAN network with a proprietary library as driver and interface. If you're writing an ADAS system, and you have a "dependency tree" that needs to be "resolved" by a package manager, you should be fired immediately. Any software that has lives riding on it, if it has dependencies, must be certified against…

You keep confirming that you don't know what you are talking about. The vendoring step happens at something like Yocto or equivalent and that's what ends up being certified, not random library repos.

"Vendoring step" You cannot make this shit up.

You're providing a library. That library has dependencies (although it shouldn't). You've written that library to work against a specific version of those dependencies. Vendoring these dependencies means shipping them with your library, and not relying on your user, or even worse, their package manager to provide said dependencies.

I don't know what industry you work in, who the regulatory body that certifies your code is, or what their procedures are, but if they're not certifying the "random library repos" that are part of your code, I pray I never have to interact with your code.

Re: A critique of package managers

#82

Post by gingerBill »

Ygg2 wrote: post #80
kunley wrote: post #78

Earlier quoted context omitted.

I don't buy it. A guy designing and then implementing a programming language has a much bigger chance to put a lot of rational thinking into the tooling like dependency manager, than a typical language consumer, who can and often is easily falling into the languages emo wars.

> than a typical language consumer, who can and often is easily falling into the languages emo wars. How is ginger bill excluded from this group? No one is more invested in a language than its creator(s). Sure, he might have given it a lot of thought, but he came up with some completely bonkers conclusions. If you don't want dependencies, DON'T IMPORT DEPENDENCIES. Don't make your dependencies extremely hard to add.

I have? Pray tell.

Re: A critique of package managers

#83

Post by jitl »

rich_sasha wrote: post #75
jitl wrote: post #49

Earlier quoted context omitted.

Rust’s big issue here is the anemic standard library. I think overall the strategy makes some amount of sense; since there’s so much crazy alchemy like depending on nightly, no_std, etc in Rust, including stuff in std has more downside in Rust than in a language that’s more stable like Go. But it’s annoying to have to deal with 3 different time libraries and 3 different error creation libraries and 2 regex libraries…

I agree, though also I note Python has an extensive standard library and isn't much better in terms of package sprawl.

Yeah, Python is a cautionary tale here, and I think one that informed the Rust stance.

Python is much older than Go, and has had more packages move from 3rd party into the stdlib to become a "battery", and then atrophy over the years while people move back to 3rd party alternatives with more features that are actually receiving maintenance. Eventually some of those modules were removed from core.

Perhaps the Go model only works when you have a very dedicated core group (for Go, mostly Google employees) around to continuously build and maintain the Cathedral of the standard library + toolchain together. Golang feels very much like UNIX (eg FreeBSD) for this reason, and Rust/Python more like Linux.

Re: A critique of package managers

#84

Post by cayleyh »

SideburnsOfDoom wrote: post #27
1GZ0 wrote: post #12

Earlier quoted context omitted.

The Author isn't arguing for not using third party dependencies. He's arguing for developers to be more conscious of the dependencies they use, by manually vetting and handling them. That screams "I've been down the package manager route and paid the price". Not inexperience.

> He's arguing for developers to be more conscious of the dependencies they use "be careful all the time" doesn't scale. Half of all developers have below-average diligence, and that's a low bar. No-one is always vigilant, don't think that you're immune to human error. No, you need tooling, automation to assist. It needs to be supported at the package manager side. Managing a site where many files are uploaded, and t…

"Half of all developers have below-average diligence" - a lot of this is also not developer choice, but environmental. So much software is developed and maintained in very constrained economic environments, often by solo devs who also have other responsibilities. The choice here often is trading some "diligence" for "meeting business requirements in the time / budget constraints" imposed by your employer.

Re: A critique of package managers

#85

Post by SideburnsOfDoom »

cayleyh wrote: post #84
SideburnsOfDoom wrote: post #27

Earlier quoted context omitted.

> He's arguing for developers to be more conscious of the dependencies they use "be careful all the time" doesn't scale. Half of all developers have below-average diligence, and that's a low bar. No-one is always vigilant, don't think that you're immune to human error. No, you need tooling, automation to assist. It needs to be supported at the package manager side. Managing a site where many files are uploaded, and t…

"Half of all developers have below-average diligence" - a lot of this is also not developer choice, but environmental. So much software is developed and maintained in very constrained economic environments, often by solo devs who also have other responsibilities. The choice here often is trading some "diligence" for "meeting business requirements in the time / budget constraints" imposed by your employer.

Absolutely true, but still indicates the need for tooling, for automation, and for oversight at the the package store.

"developers, be more conscious" isn't going to fix all the issues. In general, there are not individual effort fixes to systemic issues.

Re: A critique of package managers

#86

Post by kunley »

Ygg2 wrote: post #80
kunley wrote: post #78

Earlier quoted context omitted.

I don't buy it. A guy designing and then implementing a programming language has a much bigger chance to put a lot of rational thinking into the tooling like dependency manager, than a typical language consumer, who can and often is easily falling into the languages emo wars.

> than a typical language consumer, who can and often is easily falling into the languages emo wars. How is ginger bill excluded from this group? No one is more invested in a language than its creator(s). Sure, he might have given it a lot of thought, but he came up with some completely bonkers conclusions. If you don't want dependencies, DON'T IMPORT DEPENDENCIES. Don't make your dependencies extremely hard to add.

Yeah when speaking about emotions: the amount of emo reactions here, including shouting with all caps, lets me think we've fallen into the old story: the author kind-of praised Go, but it's unfashionable here; the contrary, the fad here is to hate Go, so the author needed to get his hate. As simple as that. The rest is just trying to hide the hate under seemingly rational arguments.

Yawn.. saw it before...next, please

Re: A critique of package managers

#87

Post by kunley »

tialaramex wrote: post #48
kunley wrote: post #10

Earlier quoted context omitted.

Inexperience of an author who develops quite successful programming language for like 10 years? Quite a bold statement. Actually his perspective is quite reasonable. Go is in the other part of the spectrum than languages encouraging "left-pad"-type of libraries, and this is a good thing.

Is it "quite successful"? How would I distinguish such a "quite successful" language from say Hare or V or are these all "successful" in your mind?

Why the need for distinguishing and an urge for comparison? We're talking about Odin, that's it. As a project that (as I understand) didn't have any big corp investment, it's impressive.

Re: A critique of package managers

#88

Post by Ygg2 »

kunley wrote: post #86
Ygg2 wrote: post #80

Earlier quoted context omitted.

> than a typical language consumer, who can and often is easily falling into the languages emo wars. How is ginger bill excluded from this group? No one is more invested in a language than its creator(s). Sure, he might have given it a lot of thought, but he came up with some completely bonkers conclusions. If you don't want dependencies, DON'T IMPORT DEPENDENCIES. Don't make your dependencies extremely hard to add.

Yeah when speaking about emotions: the amount of emo reactions here, including shouting with all caps, lets me think we've fallen into the old story: the author kind-of praised Go, but it's unfashionable here; the contrary, the fad here is to hate Go, so the author needed to get his hate. As simple as that. The rest is just trying to hide the hate under seemingly rational arguments. Yawn.. saw it before...next, pleas…

Yeah, god forbid you use bolding to emphasize your phrase on this site. It's considered emotinal response, but yours is purely logical?

I'm glad you saw through me like a Superman through a lead book. Which is to say, not at all. I wasn't even thinking of Go. Where did this come from? I never mentioned Go. I don't use it or know how it does its packaging.

Are you projecting your feelings onto me as a sort of substitute for the HN gestalt? The discussion was about package managers being evil.

Now please return to the topic at hand.

Let's say you have NPM package manager. What prevents you a rational individual from saying:

      {
         "depedencies": {}
      }

Re: A critique of package managers

#89

Post by adev_ »

alexvitkov wrote: post #81
seba_dos1 wrote: post #68

Earlier quoted context omitted.

You keep confirming that you don't know what you are talking about. The vendoring step happens at something like Yocto or equivalent and that's what ends up being certified, not random library repos.

"Vendoring step" You cannot make this shit up. You're providing a library. That library has dependencies (although it shouldn't). You've written that library to work against a specific version of those dependencies. Vendoring these dependencies means shipping them with your library, and not relying on your user, or even worse, their package manager to provide said dependencies. I don't know what industry you work in,…

> I don't know what industry you work in, who the regulatory body that certifies your code is, or what their procedures are, [..], I pray I never have to interact with your code.

You illustrate perfectly the attitude problem of the average "gamedev" here.

You do not know shit about the realities and the development practice of an entire domain (here the safety critical domain).

But still you brag confidently about how 'My dev practices are better' and affirm without any shame that everybody else in this field that disagree is an idiot.

Just to let you know: In the safety critical field, the responsibility of the final certification is on the integrator. That is why we do not want intermediate dependency to randomly vendor and bundle crap we do not have control of.

Additionally, it is often that the entire dependency tree (including proprietary third party components like AUTOSAR) are shipped as source available and compiled / assemblied from sources during the integration.

Thats why the usage of package manager like Yocto (or equivalent) is widespread in the domain: It allows to precisely track and version what is used an how for analysis and traceability back to the requirements.

Additionally again, when the usage of binary dependencies is the only solution available (like for Neutrino QNX and its associated compilers). Any serious certification organism (like the TUV) will mandate to have the exact checksum of each certified binary that you use in your application and a process to track them back to the certification document.

This is not something you do by dumping random fu**ng blob in a git repository like you are proposing. You generally do that, again, by using a proper set of processes and generally a package manager like Yocto or similar.

Finally, your comment on "v1.3.1 of libfoo" is completely moronic. You seem to have no idea of the consequence of duplicated symbols in multiples static libraries with vendored dependencies you do not control nor the consequences it can have on functional safety.

Re: A critique of package managers

#90

Post by Ygg2 »

gingerBill wrote: post #82
Ygg2 wrote: post #80

Earlier quoted context omitted.

> than a typical language consumer, who can and often is easily falling into the languages emo wars. How is ginger bill excluded from this group? No one is more invested in a language than its creator(s). Sure, he might have given it a lot of thought, but he came up with some completely bonkers conclusions. If you don't want dependencies, DON'T IMPORT DEPENDENCIES. Don't make your dependencies extremely hard to add.

I have? Pray tell.

Have what? Heavily invested in language you're building? I think that's a given.

Not clear-headed about this? https://old.reddit.com/r/programming/comments/1nbkwzt/packag...

    > gingerbill[S] 1 point 2 hours ago
    >  So a tool that enables evil is not an evil tool?
See counterpoint: hammers, freezers, cars, arrows, guns, bombs, planes, etc. Each of them *can* enable evil. Same way a package manager *can* enable sprawling dependency list.
Post reply on HN