Installing from source: an unsupported package is refused, not compiled mv_package#164. The page said a source install that cannot work fails at the compile -- which was the only outcome there was, because MVPKG could not read the systems a package declares and so attempted every one of them. It now refuses before downloading, and the compile failure means something narrower: a package that DOES claim your platform and still will not build.
Installing from source: git is preferred, not required (mv_package#160) The page was written against the clone-only behaviour and led with "Prerequisite: the git package". That is no longer true and was the wrong emphasis even then: the common case is not asking for a source install at all, it is having no binary for your platform -- which is what a new platform hits first, and what used to demand a package with native libgit2 code before anything could be installed. Leads with the automatic case now, and records that it is an ordinary install of that version (measured: curl-cmd 1.2.0 lists as 1.2.0, a --source tree lists as source). Adds a with-git/without-git table covering where the tree comes from in each case, why the tarball route uses GitHub's .tar.gz rather than its .zip, what MVPKG update does with a tree that has no origin, and that a package whose source does not compile is a fact about the package.
Installing a package from source: --source, the automatic fallback, and what is recorded The wiki had one line on source installs, and it described doing it by hand -- "clone the package's own mv_git repository and build it with the target platform's toolchain" -- which predates MVPKG install --source entirely. Documents what the client actually does: the git-package prerequisite and the error when it is missing, --source with [@ref] and an optional target dir (and where the default lands), the AUTOMATIC source build when the registry serves no binary for this system and machine, devDependencies/+ build deps read from the cloned copy, the store and lock records including why the lock pins the resolved commit and not the ref, and MVPKG update fast-forwarding a working copy in place.