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

Writing a Package Manager

antonz.org

Post reply on HN
Print view View original

51–60 of 106 posts

Re: Writing a Package Manager

#51

Post by 3np »

qwerty456127 wrote: post #47
oblio wrote: post #43

Earlier quoted context omitted.

No, it isn't. Just because someone says X does Y, it doesn't mean it does. For anything serious you absolutely verify checksums. Ideally you also mirror every dependency used so you don't care anymore about what's out there. The thinking in your comment lead to Maven range and npm general atrocities.

Every time I download someone's code I replace all the == requirements with >=s and it works perfectly (I understand there are many cases when it wouldn't). Every time an old unmaintained Linux app I need fails to start, saying it needs some libsomething.2.3 which isn't in the repos already I just symlink the libsomething.2.5 to it and it works great. Some times this even helped me to overcome bugs/vulnerabilities. B…

You are mad.

I love you.

Re: Writing a Package Manager

#52

Post by brabel »

zivkan wrote: post #40
qwerty456127 wrote: post #38

Earlier quoted context omitted.

Depending on a single specific version is wrong. A library can be changed to fix a bug without changing the interface in any breaking way. It should be possible for a user (also their package manager, automatically) to replace the library with the new version in this case.

Depending on how important supply chain security is to your industry/company/team, validating the hash of every package is critical. If an attacker can manage an interception/man in the middle attack on your CI network, the hash check provides protection. If an attacker compromises the server you get packages from, having a hash provides protection as well. Automatically trusting the server's response to be correct,…

Your argument supports the idea of getting rid of the lock file and instead committing the hash in the original dependencies file - so that it's never an automatic process to update the hashes/versions.

Re: Writing a Package Manager

#53

Post by layer8 »

deepsun wrote: post #14

Sounds like Maven had all this solved many years ago. Yes, it cannot run arbitrary code, like NPM does, it just copies files, but the dependencies and specfiles were there from the beginning.

Maven didn’t support transitive dependencies from the beginning.

Re: Writing a Package Manager

#54

Post by layer8 »

BearhatBeer wrote: post #5

I think some day rather than the current paradigm, even including declarative package managers and environments and distros, the future will be per-user and even per-app chrooting or jails, or something similar. Apple already uses something like this today. Many people who are smart about information security have one login for shopping and banking and bill pay, one for their business, and one for cruising the web or…

How do you build the app with its dependencies without a package manager?

Re: Writing a Package Manager

#55

Post by throw10920 »

qwerty456127 wrote: post #38
pharmakom wrote: post #26

Earlier quoted context omitted.

A version number is just a label, and labels are mutable. A lock-file containing hashes will always resolve to the same packages (or fail).

Depending on a single specific version is wrong. A library can be changed to fix a bug without changing the interface in any breaking way. It should be possible for a user (also their package manager, automatically) to replace the library with the new version in this case.

It's not wrong to depend on a single version, just suboptimal.

Exhaustively testing every combination of dependencies with your project is infeasible for any non-trivial set of dependencies. The "is compatible with" relationship present in some package managers (e.g. ~= in pip) isn't guaranteed to work because packages can "lie" about their compatibility.

Sure, it's better to have some kind of way for a piece of software to specify that it depends on foo 3.x instead of tying it to a specific release, but at least being able to specify some dependency is better than not at all. In the worst case, the user can treat the "required" version as a suggestion/guide, override that version with whatever they want, and see if the code works.

Re: Writing a Package Manager

#56

Post by cobbzilla »

qwerty456127 wrote: post #38
pharmakom wrote: post #26

Earlier quoted context omitted.

A version number is just a label, and labels are mutable. A lock-file containing hashes will always resolve to the same packages (or fail).

Depending on a single specific version is wrong. A library can be changed to fix a bug without changing the interface in any breaking way. It should be possible for a user (also their package manager, automatically) to replace the library with the new version in this case.

If you’re going for guaranteed repeatable builds (for example you’re using Bazel) then you have no choice. Dependencies must have a single resolution.

Re: Writing a Package Manager

#57

Post by oblio »

wizzledonker wrote: post #44
oblio wrote: post #41

Earlier quoted context omitted.

There isn't any. There are a few partial ones like conan, etc. And many people in the community are against it, you'll hear stuff ranging from "just use the distro package manager" to "don't use any, make it a single file library". Personally, I'd say all hope is lost.

Just because I’m curious, in what respect is Conan a “partial” package manager? Within the constraints of existing C++ projects and the variance of their build systems, I can’t imagine how to do it differently. In my experience, most of the value of Conan is with creating packages yourself when needed. You can then self-host a Conan remote and have pre-compiled binaries ready development. Having a conan recipes repos…

Well, I'll expand.

For 95% of Java devs, JavaScript devs, Python devs, if it's Open Source and it isn't on Maven Central, NPM, PyPi, it might as well not exist.

The reverse is true, if you have any library or tool worth a damn, it's there.

Re: Writing a Package Manager

#59

Post by qwerty456127 »

throw10920 wrote: post #55
qwerty456127 wrote: post #38

Earlier quoted context omitted.

Depending on a single specific version is wrong. A library can be changed to fix a bug without changing the interface in any breaking way. It should be possible for a user (also their package manager, automatically) to replace the library with the new version in this case.

It's not wrong to depend on a single version, just suboptimal. Exhaustively testing every combination of dependencies with your project is infeasible for any non-trivial set of dependencies. The "is compatible with" relationship present in some package managers (e.g. ~= in pip) isn't guaranteed to work because packages can "lie" about their compatibility. Sure, it's better to have some kind of way for a piece of soft…

Why not just replace the "requires" semantics with "has passed tests with" and "has failed tests with" and let the host decide?

Re: Writing a Package Manager

#60

Post by grumblingdev »

wizzledonker wrote: post #42
Eddygandr wrote: post #39

Bit of a tangent here but what’s a pip/npm/cargo like package manager for C++? For example ‘pip install boost’? I’ve never worked it out for hobby projects and never worked with it commercially

The closest thing we have at the moment is conan[1]. It’s a cross platform package manager that attempts to implement “integrations”, whereby different build systems can consume the packages[2]. This is a big problem with package management in C/C++, there’s no single, standardised build system that most projects use. There isn’t even a standardised compiler! So when hosting your own packages using Conan, often you n…

The cpp ecosystem is insane. I don't know how it got so out of hand. At the end of the day you are just a running a bunch of clang/gcc cli commands. It's really, really, really simple. But all these commands are generated, and the user becomes so detached from what they are actually doing, and then they are left with an error about one of these commands not working, and then they need to dive into this huge monstrosity to figure out what is making a command do something.

Declarative build systems obfuscate so much without providing the proper debugging and error-handling capabilities.

Build systems should be imperative and type-checked. A simple script that a user can step through and observe what is happening.

Makefiles suck because they are not type-checked.

The only abstraction you need is some kind of dependency graph. But then it should be completely transparent to the user so they can easily understand it.

Post reply on HN