On Wed, 04 Sep 2013 08:48:16 GMT, Sönke Ludwig wrote:

There are the two directories /var/lib/dub/ and ~/.dub/ where it installs source packages (more or less just a verbatim copy of the git repository contents, except that the package.json gets annotated with an additional "version" field). Installing binary files was/is on the agenda, but mostly just for application packages, as it is too easy to break binary compatibility when using precompiled libraries (e.g. by using different -version= identifiers) for it to make much sense in the current ecosystem of libraries. But this is something that mostly Robert Klotzner was driving forward and now he is still busy with his studies, so this may take a while until it is picked up again.

So a package manager that doesn't install packages, hmm...

Yes. It has gained some additional support here since the early days:

  • "dub add-local <PATH>" will register a single package folder to dub
  • "dub add-path <PATH>" will register a directory containing multiple packages to search
  • a DUBPATH environment variable can be defined along the lines of go's GOPATH
  • package versions in all those cases are inferred using "git describe", checking a "version" field in package.json, or falling back to ~master (in this order)
  • private registries can be specified using --registry=URL or by putting a "registryUrls" field in the user or system configuration file (e.g. ~/.dub/settings.json)
  • being able to specify a git URL for a dependency is planned, but still needs some details to be worked out

I see.

Currently, whenever a version based dependency is given (e.g. ">=1.0.0"), only tagged versions are considered. Similarly, when a branch dependency is given (e.g. "~master") only the HEAD of that branch is tracked. Two extensions to this have been considered up to now:

  • Make it possible to also specify exact commit SHA's
  • Let a version based dependency using ">=" fall back to "~master" in case the same package is also referenced as "~master" by some other involved package (thus assuming that version tags are always on master or at least that master is source compatible with tagged versions and not something completely different)

I've been looking at the registry, http://code.dlang.org/, it seems I can't tell the registry what's available?