I really don’t understand why the tight integration with github is necessary. I think a tight integration with git is sufficient.
The package manager could be designed to just interpret each specified dependency as a mapping of git cloneable stuff to a git commitish.
As git clone can accept different protocols and even paths to local folders containing a git repository, this would solve all use cases I have. Instead of only accepting a version number, the package manager could accept anything that git accepts in a git checkout: this could be a tag (maybe in valid version number format) or the sha of a commit.
By adding shorthands, e.g. rewriting cloneables in the format “author/project” to “https://github.com/author/project.git” this would even be 100% backwards compatible.
To download a package, instead of getting the zipball from github, just make a shallow fetch with --depth 1 of the git repository URL.
Are there any downsides to this model compared to how it currently works?
A tight integration with git can also be used to keep a snapshot of the Elm package database.
Instead of always getting the whole state of the package ecosystem using a http request, the official rust package manager for example, gets the newest list of published packages by updating its local checkout of https://github.com/rust-lang/crates.io-index. Which is really ingenious since you get diffing and compression for free.
Edit: seems like Skinney/ elm-git-install follows exactly this idea 