Namespaced packages and pseudo packages.

[jonathanmarvens]

We've been using clib(1) at our startup and it's been very helpful. However, there are two main things I'm wondering if we could do better at.

The first thing is namespaced packages. We use several C libraries for one of our services, the main one being ccv for most of our computer vision needs. The way we have our dependencies structured right now is with two directories: clib-deps/ and deps/. For packages with clib(1) support, we run clib install -o clib-deps blah/blah beep/boop, and all other packages, such as ccv, end up in deps/ (which is done manually). The reason we do this this way is, of course, because clib(1) installs are not namespaced, and we don't have a backend like the npm Registry to help out. So, I'm wondering, since we rely on GitHub as our equivalent (kinda) to the npm Registry (which I think is a good thing), can we make it so that clib(1) packages are namespaced based on the GitHub username/organization? I'm willing to make the commits to support this behavior if we can agree on it.

The second thing is pseudo packages. Because the majority of the libraries we use don't support clib(1), we have to manually manage them. I think we can fix this with what I'm calling "pseudo packages". A pseudo package would be nothing more than a repo with a package descriptor, where the package descriptor would just describe how to grab the real library. For example, this would allow me to just create a pseudo package for ccv and just pull it in using clib(1). However, in order to build a robust system for this, I think we would first need to work on #51 (clibs/clib-package#3).

I would really love to hear thoughts on these suggestions!

Thanks.

• Jonathan

[stephenmathieson]

What do you mean namespaced? Are you suggesting putting installing deps in ./deps/owner/name/ (for example, ./deps/clibs/list)? If so, this would be a huge breaking change, so I'm pretty hesitant and am not sure I understand the benefit.

---

The pseudo package makes sense (and would resolve #54). I assume we'd have to explicitly list the required files for the package, which may prove to be more work than it's worth...

However, in conjunction with #51, we may be able to support something like this:

{
  "dependencies": {
    "foo/bar": {
      "src": ["baz.c", "bang.h", "woo.c"],
      "version": "1.2.3",
      "url": "http://some.git.host/{owner}/{name}/{version}/{file}"
    }
  }
}