Unsurprisingly, correctly handling the cases of non-release packages added by Pkg.add, packages added by Pkg.dev, and arbitrary release versions possibly spread over multiple registries has proven somewhat complicated. In order to have some hope to tame the complexity, I have refactored much of the code. I am hoping it can be somewhat clear in the end, with some organization and comments.
This does have a lot of nice features though:
analyze_manifest allows analyzing all the code specified in a manifest
tree_hash's are checked post-download, when available (i.e. not a dev'd package). Corrupted but non-error'd download should count as not-reachable, instead of getting garbage results.
code from installed packages (.julia/packages/name/slug) is analyzed instead of being re-downloaded (and is depot-agnostic)
in particular, if you have an instantiate'd manifest, no code needs to be downloaded to analyze it. It's fast!
analyze(name) now defaults to the latest release version, instead of the latest trunk. In particular, downloads can be skipped if this version is installed.
analyze allows choosing a version, including :stable for latest release and :dev for unreleased trunk branch
handles multiple registries. Packages can be looked up in any reachable registry, and even correctly supports the same package being registered in multiple registries, possibly w different versions in each
code paths are somewhat streamlined. We always flow from "input" (name, url, directory, module, etc) to PkgSource (Release, Dev, Added, or Trunk representing the valid ways to access a package), with obtain_code to obtain the code for each possible source, to analyze_code which is agnostic to how the code was obtained.
release/dev/added are ways to get a package in a manifest. Trunk lets you pass just a URL (and subdir) to get the latest version. This sounds like what dev does with a URL, but the implementation is different; Pkg.dev will clone it then update the manifest with a local path. So Dev objects track local paths, while Trunk objects track remote URLs.
TODO:
[x] try to handle non-release versions in Manifest.tomls
[x] handle dev with remote URL & subdir ?
[x] cleanup
[x] docs update
[ ] stretch: try to resolve stdlibs relative to version-in-manifest when analyzing manifest, instead of current julia version
[x] lots of tests -- many new features, some fairly complicated situations, needs a lot of tests. Current tests will fail due to refactoring.
[x] Base.show for Release, Added, Trunk, Dev
[x] analyze Added from URL
[x] analyze Added with path
[x] analyze Dev with path
[x] analyze Trunk
[x] analyze Release
[x] zero-arg analyze
[x] find_packages_in_manifest with non-release packages
[x] ...maybe multi-registry stuff. I think this can be tested without tooo much effort by faking a 2nd RegistryInstance by copying and modifying the one associated to General.
Closes #70
Unsurprisingly, correctly handling the cases of non-release packages added by
Pkg.add, packages added byPkg.dev, and arbitrary release versions possibly spread over multiple registries has proven somewhat complicated. In order to have some hope to tame the complexity, I have refactored much of the code. I am hoping it can be somewhat clear in the end, with some organization and comments.This does have a lot of nice features though:
analyze_manifestallows analyzing all the code specified in a manifesttree_hash's are checked post-download, when available (i.e. not a dev'd package). Corrupted but non-error'd download should count as not-reachable, instead of getting garbage results..julia/packages/name/slug) is analyzed instead of being re-downloaded (and is depot-agnostic)instantiate'd manifest, no code needs to be downloaded to analyze it. It's fast!analyze(name)now defaults to the latest release version, instead of the latest trunk. In particular, downloads can be skipped if this version is installed.analyzeallows choosing a version, including:stablefor latest release and:devfor unreleased trunk branchPkgSource(Release,Dev,Added, orTrunkrepresenting the valid ways to access a package), withobtain_codeto obtain the code for each possible source, toanalyze_codewhich is agnostic to how the code was obtained.Trunklets you pass just a URL (and subdir) to get the latest version. This sounds like whatdevdoes with a URL, but the implementation is different; Pkg.dev will clone it then update the manifest with a local path. SoDevobjects track local paths, whileTrunkobjects track remote URLs.TODO:
Base.showforRelease,Added,Trunk,DevAddedfrom URLAddedwith pathDevwith pathTrunkReleaseanalyzefind_packages_in_manifestwith non-release packages