[deleted]
Ask HN: Why does every package+module system become a Rube Goldberg machine?
61–70 of 222 posts
Re: Ask HN: Why does every package+module system become a Rube Goldberg machine?
#62Why do we need different systems for all languages, all Linux/Windows/Mac/Android distributions. Why are no one reusing what is already there. It might seem like an easy problem to fix. Rust, Java and Go certainly has their problems too, not quite sure why people feel they are good examples. I think the world is complicated and you will in the end need to support compilations/installations on AmigaOS 2.05 on m68k run…
Because I don't want my side project to share dependencies with system-wide python.
Re: Ask HN: Why does every package+module system become a Rube Goldberg machine?
#63Earlier quoted context omitted.
It's not actually tied to GitHub. If GitHub died tomorrow, they would easily be able to move on and host the packages somewhere else. There's no way to do this without hosting. Also, there is a way to pin a version or commit. Julia for example always stores the exact commit information for all packages in the "Manifest" file. There are also straightforward ways to demand certain versions and package maintainers have…
There will be a mess of dependencies of old projects that depend of projects that have since moved off GitHub, there will be name clashes between GitHub projects and BitBucket projects etc. These ecosystems are very much dependent on GitHub, and if/when anything permanent changes, it will be a mess to move off of it.
> there will be name clashes between GitHub projects and BitBucket projects etc.
The package manager requires a canonical URL for the git repo. The location of dependencies doesn't matter, for example Github repos with Bitbucket dependencies work fine. The FastLapack packages lived on BitBucket at one point, and then migrated to Github, and that happened without a hitch to upstream packages like LinearSolve.jl or DifferentialEquations.jl.
Also, it takes a one line change to General change a package's from Github to BitBucket. It didn't take me more than 2 minutes when I tried. Did you not have a similar experience? Can you show the PR where you gave it a try? Or is your response just speculation?
The package server mirrors the repos, so even if these services went down it would not break the dependency chain (developers wouldn't be able to easily update the packages, but the installations and all would still work). So if tomorrow Github decided to make all of the code private for some odd reason, Julia's package server would continue to serve the current versions.
Re: Ask HN: Why does every package+module system become a Rube Goldberg machine?
#64You haven't explicitly enumerated the things about those packaging systems which seem "Rube Goldberg" to you; nor have you mentioned either Golang or Rust's package management. I'm pretty happy overall with Golang's package management, and from my little exposure to Rust's package manager, it seems fairly decent as well. Do either of them strike you as "Rube Goldberg"? What aspects, and why?
Package management in Go is weird but it works well. You just run go mod tidy from time to time and you're good. Add a module proxy if you want to prevent issues with repositories disappearing and you're gooder.
There's already a module proxy (pkg.go.dev) by default in new versions of Go, for just that purpose. In fact, one could argue that the automatic proxy is "Rube-Goldberg"-like: It works great normally, but if you need, for instance, to pull from a repo you just pushed to, you have to track down the magic rune to type to get `go get -u` to pull directly from your repo, rather than using the cached copy at pkg.go.dev.
Re: Ask HN: Why does every package+module system become a Rube Goldberg machine?
#65You might want to check PackagingCon https://www.youtube.com/watch?v=bdX1XXpLFYY&list=PLl386dCR5Q...
Re: Ask HN: Why does every package+module system become a Rube Goldberg machine?
#66I don't see many complaints about Free Pascal/Delphi. You want a unit? Get it, add it, use it. No 3rd party Rube Goldberg contraption needed. No package managers or dependency resolvers, no special build tooling, no lock files. No constantly having to run updates and figure out what they broke by way of transitive dependencies. Just get what you need and use it. I haven't, however, developed enough professionally wit…
There are two problems that make package management hard, neither which are tackled by a "Get it, add it, use it" approach. Dealing with cross platform issues and package dependencies. If we ignore these two problems then package management is easy. We could make a 'rule' that packages cannot depend on other packages, and that packages only support the single OS/CPU combo they were originally developed for, but that will cause other problems.
Re: Ask HN: Why does every package+module system become a Rube Goldberg machine?
#67> In contrast, we apparently have no "package management theory". We have not figured out the primitives required to express dependencies We have a good hunch. The basic theory behind Nix definitely goes in the right direction, and if we look away from all the surface-level nonsense going on in Nix, it's conceptually capable (e.g. [0]) of being a first-class language dependency manager. For this to work at scale we'd…
What's a good source, for someone who has never used nix, to read about its conceptual model and how it is different from contemporary dependency managers?
There really isn't one that I know of. There's the original thesis[0], but it's from a different time and it focuses only on the package management (~ for a distribution) aspect.
Everything else is mostly written to teach people how to use Nix, and the more recent the thing is the more it will focus on surface-level features of the C++ implementation of Nix.
Re: Ask HN: Why does every package+module system become a Rube Goldberg machine?
#68Because most developers don't learn from other projects and redo the same mistakes. It's a form of not-invented-here syndrome and you can see it in all the comments defending their favorite language.. > we apparently have no "package management theory". Apparently. In reality there's been plenty of research - and for decades - that is not being used.
> In reality there's been plenty of research - and for decades - that is not being used.
Can you link what you're referring to? Genuine request, I'm curious and keen to learn more.
Re: Ask HN: Why does every package+module system become a Rube Goldberg machine?
#69Earlier quoted context omitted.
> Languages have different ways of importing and installing dependencies They're not actually different. They call things differently, and they have different methods of passing the required lookup paths/artifacts/sources to their compilers/interpreters/linkers, but in the end all of them are conceptually the same thing.
>but in the end all of them are conceptually the same thing The concept of a programming language isn't what people use, but the concrete reality of specific implementations on specific hardware. You could also say that a coffee cup and a donut aren't actually different because they're topologically the same... but the facts on the ground do actually matter.
It absolutely does matter in this case. We have written implementations of this concept for very different languages (Go, Common Lisp, Erlang, C) and the conceptual equality means that nothing is different at the core, only at the edges (where you integrate with each snowflake's particular flavour of "what are the names of the command-line arguments to the compiler" and so on).
Re: Ask HN: Why does every package+module system become a Rube Goldberg machine?
#70Earlier quoted context omitted.
I do not understand what you mean by modules, and how Rust and not Java or Python is helped by this.
Modules typically refers to a unit of code that packages together several types and functions (and/or other top-level concepts in your language, e.g. macros, templates, metaclasses, namespaces, packages) with an explicitly declared public interface, while still allowing these types and functions to have additional internal APIs that are not exposed. A module has to declare what other modules it depends on explicitly.…
> C++ breaks C's module system because of its heavy reliance on templates, which have to be entirely declared in the public API and can't have any internal API of their own; and because the compiler needs to know the total size of a class, including the size of its private members, to compile any code which references objects of that class.
Other languages with generics and modules do just fine by having the required metadata on the module, e.g. Eiffel, Modula-3, Ada, OCaml,..., which is what C++20 modules do as well.
I have been using C++ modules on VC++ for quite some time, and while there are still some warts on the overall experience, they work quite alright.