Live data from Hacker News

The fundamental problem of programming language package management

blog.ezyang.com

71–73 of 73 posts

Re: The fundamental problem of programming language package management

#71

Earlier quoted context omitted.

The problem you cited before is supposed to be easy, but in practice, software development that uses 3rd-party software is destined to run into conflicts. You found portability issues, platform-dependent issues, environment/configuration issues, and multi-layer software dependency issues. These all happen regularly when OS maintainers have to package software for release. They spend thousands of hours to resolve [by…

I think it’s a stretch to call a tool like npm, which currently offers 90,000+ packages, a “small, bespoke, use-case-specific” solution. I’m also fairly sure most people publishing their code via npm’s index aren’t spending “thousands of hours” resolving conflicts with other packages by hand; certainly no-one is manually checking over 4 billion pairwise combinations of those packages to make sure they don’t conflict.…

Again, nothing you use works without it being designed specifically to work that way. You can't use Visual C++ to build software that was designed for Linux without writing portable abstractions and host targets for both platforms, and it definitely won't work on two different architectures without being designed for the endianess and memory width of each. It's bespoke because it's designed for each use case. It simply will not work on anything it wasn't designed for.

And no, it isn't code publishers that spend thousands of hours resolving broken and incompatible builds, it's release maintainers. Go look at bug lists for CentOS. Look at the test trees for CPAN. It is literally mind numbing how much shit breaks, but it makes total sense when you realize it's all 3rd party software which largely is not designed with each other in mind. Somebody is cleaning it all up to make it work for you, but it sure as shit ain't the software authors.

Once you develop enough things or maintain enough things you'll see how endlessly complex and difficult it all is. But suffice to say that the system we have now is simpler than the alternative you are proposing.

Re: The fundamental problem of programming language package management

#72
post #45
post #38

Earlier quoted context omitted.

I am a Haskell programmer who got to use OPAM when installing Coq (HoTT version) recently. It was surprisingly nice. Also, you can pick which version of the compiler to run, and have it manage switching everything. It seemed like it was years ahead of cabal, but that might just be because I only used it a little, I don't know. But there are some things to learn from OPAM. Do you have a blog post like this, or somethi…

We're planning a post after the ICFP rush next week dies down, but there's a rather specific one on the new pinning workflow in OPAM 1.2 here: http://opam.ocaml.org/blog/opam-1-2-pin/ (How to pin a development is central to the day-to-day development workflow of OCaml/OPAM users and quite annoying to change after-the-fact, so we're eager for feedback on this iteration before we bake it into the 1.2.0 release). The OP…

(It looks like your rss feed is broken somehow. If I subscribe, and then try and view your site I get about:blanks, at least in InoReader. But I can view it in the reader fine.)

I'm quite excited.

Re: The fundamental problem of programming language package management

#73

Earlier quoted context omitted.

I think it’s a stretch to call a tool like npm, which currently offers 90,000+ packages, a “small, bespoke, use-case-specific” solution. I’m also fairly sure most people publishing their code via npm’s index aren’t spending “thousands of hours” resolving conflicts with other packages by hand; certainly no-one is manually checking over 4 billion pairwise combinations of those packages to make sure they don’t conflict.…

Again, nothing you use works without it being designed specifically to work that way. You can't use Visual C++ to build software that was designed for Linux without writing portable abstractions and host targets for both platforms, and it definitely won't work on two different architectures without being designed for the endianess and memory width of each. It's bespoke because it's designed for each use case . It sim…

You can't use Visual C++ to build software that was designed for Linux...

Sure you can. Projects of all scales do this all the time. Have you never heard C described as being portable assembly language?

Unless you are writing low-level, performance-sensitive code for something like an operating system or device driver, usually details like endianness matter only to the extent that they specify external protocols and file formats. I would argue that this sort of detail is normally best encoded/decoded explicitly at the outer layers of an application anyway.

Obviously if you rely on primitive types like int or long in C or C++ having a specific size or endianness, or if you assume that they will be equivalent to some specific external format, you’re probably going to have problems porting your code (and any package containing it) across some platforms.

However, that issue does not contradict what I proposed. It’s perfectly viable — indeed, it’s inevitable — to have packages that are only available on some platforms, or packages which depend on different things across platforms. That’s fine, as long as your packaging system doesn’t assume by default that the same thing works everywhere.

And no, it isn't code publishers that spend thousands of hours resolving broken and incompatible builds, it's release maintainers.

Who is the “release maintainer” who made those jQuery libraries I mentioned in my extended example above play nicely together?

Again, this issue does not contradict what I proposed anyway. In my ideal world, if packages are incompatible or don’t have sufficient dependencies available on a certain platform, you just don’t list them as available for that platform in whatever package index they belong to. Once again, this is no harder than what a bunch of different package management tools do (or fail to do) right now.

Post reply on HN