This is some nice-to-have thing for later on.

Basically the idea is that you can create a repository* that overlays a Phragment path and serves the contents up as a NuGet, Maven, etc artifact repository. These repositories would automatically expose versioning information and calculate the necessary metadata for packages so that packages don't actually need to be built during a build. As an advantage, this means you can serve up the same package / content in multiple differerent repository formats.

For example, I could create a repository that overlays a directory fragment that looks like:

• myrepo
  • packageA/
    • example.exe
    • lib.dll
  • packageB/
    • other.dll

In the NuGet case, the packageA and packageB directories are each exposed as a package called packageA and packageB. The snapshots that are against these fragments becomes the package versions that are available for download; this significantly reduces the management in publishing and making packages available (if you want a new version, just snapshot in Phragment and away you go; NuGet's publish API would presumably map to snapshotting as well).

Generally this covers off the area that a tool like Artifactory might be used for, although Artifactory is far more complex and also deals with issues like proxying and caching remote repositories, as well as virtual repositories that aggregate multiple repositories together.

This could be used in T5055 somewhat, but I doubt it given that Phabricator PHP tends to be distributed via Git repositories.

* I'd recommend a different term so it's not confused with source control