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

91–100 of 106 posts

Re: Writing a Package Manager

#91

Post by pxc »

qwerty456127 wrote: post #59
throw10920 wrote: post #55

Earlier quoted context omitted.

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?

This is basically what I daydream about for Nix some day (Nixpkgs doesn't currently involve any dependency resolution at all). Just recording successful version combinations (both of a package declaration and source version and dependency versions) would let us add versioning metadata and save historical package versions in-repo (or in an ancillary repo) without actually changing how the monorepo is built/used.

Re: Writing a Package Manager

#92

Post by czscout »

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…

Isn't this already how Android handles app permissions? Each application runs as its own user for the sake of security. The Application Sandbox is a pretty cool interpretation of the long existing Unix user/group paradigm.

Re: Writing a Package Manager

#93

Post by pxc »

pmontra wrote: post #28
salawat wrote: post #20

Earlier quoted context omitted.

Hard pass. I don't need Microsoft securing my calculator from me, thank you very much. If I need it that badly, I'll build it myself.

My calculator is bc -l in a terminal but I'd bet that there are calculator apps with network access to display ads, sync to the same app on other devices, save past calculations to the cloud, and get plugins. I found one with some of those features and some more, with only one minute of googling https://apps.apple.com/us/app/graphcalcpro2go/id1091870099 That's for iOS but why not on Windows or Android? I'd be surpris…

Sandboxing is a nice backstop no matter what you're running, because it can help protect you from vulnerable software as well as malicious software.

But it's much more urgent in ecosystems where the norm is to install untrusted, proprietary software supplied directly from developers/publishers with minimal real human oversight from anyone.

A lot of Linux users rely just on the distro itself for their software, which is way, way safer than the way people install software on macOS, iOS, Windows, or Android. This is probably part of why desktop Linux has lacked these facilities as a default for so long, and also why Flatpak sandboxing is seen by so many users as 'about' proprietary software.

It's definitely needed, by now, though. There's still a fair bit of proprietary software that has strong network effects which compel even some users of libre operating systems, like Zoom, Slack, and Discord. It's way better to install those with sandboxing than give them access to the normal packaging mechanisms whose design assumes a level of trust and social oversight that's just not there for third-party, vendor-provided packages and repos.

Re: Writing a Package Manager

#94

Post by ljm »

mijoharas wrote: post #21

It's surprisingly to me that no-one has built a asdf style package manager. (I'm not talking about system package managers, their language software packages are always out of date and get installed globally instead of locally to a project). Having a unified interface to a package manager per language that will use the languages registry could be really nice (I guess you'd have some core dependency management function…

You could argue that Bazel, Nix and Guix solve that problem but they introduce a lot of complexity as a result because it's not a simple abstraction. Hell, you could probably pull it off somehow in Cmake if you placed no value on your sanity. Most standard lib package managers double up as build tools for bundling your code after all.

It's a totally different problem space than the one asdf aims to solve, which is just managing multiple independent versions of some programming language binaries in a consistent way, so you're not dancing between nvm, rvm/rbenv/chruby, virtualenv, etc. etc.

Re: Writing a Package Manager

#95

Post by salawat »

pxc wrote: post #93
pmontra wrote: post #28

Earlier quoted context omitted.

My calculator is bc -l in a terminal but I'd bet that there are calculator apps with network access to display ads, sync to the same app on other devices, save past calculations to the cloud, and get plugins. I found one with some of those features and some more, with only one minute of googling https://apps.apple.com/us/app/graphcalcpro2go/id1091870099 That's for iOS but why not on Windows or Android? I'd be surpris…

Sandboxing is a nice backstop no matter what you're running, because it can help protect you from vulnerable software as well as malicious software. But it's much more urgent in ecosystems where the norm is to install untrusted, proprietary software supplied directly from developers/publishers with minimal real human oversight from anyone. A lot of Linux users rely just on the distro itself for their software, which…

...Why not use Jitsi?

I'm also in the process of whipping through getting prosody (a subcomponent on which jitsi is built) set up in such a way as to also be able to handle most of what people would use Slack or Discord for.

The primitives for much of the modern corpo-ware environments have been available for a while. The best part is that those you build from scratch don't even require extra firewall config to nuke the telemetry of. Just leave that part out!

Re: Writing a Package Manager

#96

Post by mi_lk »

nalgeon wrote: post #74
brabel wrote: post #25

The author added a lockfile without understanding why they exist. A lockfile is meant to "freeze" dependency version resolution when package authors can specify dependencies on other packages using version ranges... it also "freezes" choices of transitive packages' versions when different packages depend on the same one, but with different versions. They chose to not handle package dependencies at all, and I believe…

There is quite a difference between "the author added a lockfile without understanding why they exist" and "I really don't see why they added a lockfile". It's better to start with the latter if you seek to understand, not attack.

FWIW, cynically speaking, more often than not "I really don't see why ..." roughly translates to "You don't know what you are doing ..." in business dialogue

Re: Writing a Package Manager

#97

Post by pxc »

salawat wrote: post #95
pxc wrote: post #93

Earlier quoted context omitted.

Sandboxing is a nice backstop no matter what you're running, because it can help protect you from vulnerable software as well as malicious software. But it's much more urgent in ecosystems where the norm is to install untrusted, proprietary software supplied directly from developers/publishers with minimal real human oversight from anyone. A lot of Linux users rely just on the distro itself for their software, which…

...Why not use Jitsi? I'm also in the process of whipping through getting prosody (a subcomponent on which jitsi is built) set up in such a way as to also be able to handle most of what people would use Slack or Discord for. The primitives for much of the modern corpo-ware environments have been available for a while. The best part is that those you build from scratch don't even require extra firewall config to nuke…

Jitsi meet is a pretty easy one to convince others to use, since it works in the browser and requires no accounts.

For the others, it can be more work.

Either way, the reality is that many people install those untrustworthy proprietary apps insecurely today, using vendor-provided DEBs that have a history of huge misbehavior and serious security vulnerabilities.

Re: Writing a Package Manager

#98

Post by 10000truths »

grumblingdev wrote: post #60
wizzledonker wrote: post #42

Earlier quoted context omitted.

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 monstrosi…

> Build systems should be imperative and type-checked.

Perhaps Meson fits the bill for you?

Re: Writing a Package Manager

#99

Post by basique »

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…

> Is having a program superglued to an outdated library with known (and fixed already) bugs really what you want?

It is not superglued. If you want to update dependencies, just remove the lockfile and reinstall everything. The main reason people do this is because just updating a library without the program knowing by not specifying the exact version leads to behaviour silently changing, which is terrible (especially on CI!)

Post reply on HN