Hacker News Reader

Comment by imiric | Hacker News Reader

Interesting, thanks for sharing.

The choice of Python for writing the package management tool is curious. Besides the fact that writing such a tool from scratch is a large undertaking in and of itself. I wish more Linux distributions just adopted a transactional tool like Guix instead of rolling their own. Doing upgrades safely and being able to rollback easily is a huge benefit for end users that it's hard to believe more distros haven't adopted it. We shouldn't have to reinvent the wheel every time.

View on HN

Python isn't that unusual, dnf and yum on Redhat are both written (primarily) in Python. Agree with you though, I get the appeal of writing your own package manager but...

Really not unusual. In Debian, while dpkg is in C itself (and still be for the foreseeable future), more and more apt tools are rewritten in Python.

Gentoo's Portage also.

the reason python was used is because of its portability and robustness; it can be made to work (without problems) on pretty much any platform, plus it's omnipresent and has an extensive enough standard library to write things without pulling in tons of dependencies

it's also not actually a package management tool per se (that's handled by apk-tools) but really just a build system (it creates apk repositories) similar to ports, void-packages, etc.

i'm also a Void Linux developer, and the new system is based on my experiences with xbps-src (trying to avoid its problems)

Why is writing a package management tool a large undertaking? What specifically makes it difficult or time-consuming?

It's a deceptively complex with a lot of edge cases. Dependency resolution is a difficult problem, as are transactional updates. And you want it to be something that is bulletproof, since broken packages are a nightmare. It's not that hard to get something usable, but it can take a lot of effort to get something competitive with what people have come to expect from existing mature package managers.

What's hard about dependency resolution? Aren't there off-the-shelf algorithms that solve this? At the very least, one could just lift code from other open-source tools, such as Aptitude or Yum.

Dependency resolution is NP-hard. There are existing algorithms and libraries that solve it adequately despite this, but because they usually rely on some heuristics or simplifications they come with steep tradeoffs and can be quite complex to use.

Sure you could lift code from other tools that do a good job. That's the point, if you start from scratch you have to recreate all that effort (which is considerable).

Guix is gpl licensed, which Chimera doesn't want to include in the base system.

Reply on news.ycombinator.com