the package manager we need

packages.md

Git tracks the history of changes, but in a pm we don't really care about the history, at least not when we are installing. This is the properties that I think we do need.

• security: It must be possible to check the current deps, and know if a single bit has been flipped.
• replication: It must be possible to share that hash, and someone else would do pm checkout <hash> and get exactly the same code as you.
• determinism: If I install X, Y then Z, and you install Z, then X then Y, we should get the same dep tree. If those deps have deps that need to be shuffeled around, then it should do that and keep it always optimal.
• portability: package management is too hard a problem to roll another one for every language. They all suck, more or less. This should be usable for any language, or things that have dependencies.
• conflicts: the best thing about npm is that it allows two modules to depend on different versions of another module. This generally makes development easier. but sometimes there is a global module that there can only be one of (framework, type definition, etc) also, some languages only support singly-versioned modules. Also, sometimes you might want to resolve a flat tree to optimize file sizes.
• speed. it must be fast. if an install takes too long, I get distracted.

These are the properties that I think we need. There are also other areas, like, how are module names assigned, and who can update what, that could also be improved, but those things are not as computer-sciency and it's not as objective.

I hear tell of a legend of something that @markhibberd was cooking up once, but ultimately decided not to push ahead with, at least not in an increasingly fickle opensource landscape.

Mark - is it something that you'd consider picking up again / exposing in part, or at least feeding into the design into a language agnostic solution if some others were happy to do some of the heavy lifting?

@DamonOehlman I do work on it occasionally - will probably use it for work things at some point - but unlikely I will push it out anytime soon. More than happy to discuss, details, problems e.t.c. with anyone who will listen. Obligatory link to rants: it is not the best presentation of material, but this is what I presented at strangeloop last year - https://speakerdeck.com/markhibberd/towards-annex-a-fact-based-dependency-system - https://www.youtube.com/watch?v=JjYAnBhF2JU

And comments on actual points above:

• "security" and "conflicts" can be somewhat at odds in many situations (e.g. the number of openssl versions I have greatly affects vuln. surface area).
• "security" is far more nuanced/complicated than code changes, w.r.t trust, etc... but there is a bit of prior art around things like TUF.
• "portability" very strong nod of approval.
• "determinism" this is very important, but the order of install problem is not the biggest one IMO, need to worry about more what happens over time (i.e. resolving now vs next year).

All sounds pretty reasonable / non-controversial.