Browse the NPackage source on GitHub
I implemented the local package database idea that I mentioned last weekend. Now the NPackage client downloads a packages.js file that describes every version of every package; now you don't have to specify full package file URLs with version numbers. I've also switched to JSON syntax for the package files, instead of using my hand-made Yaml-ish parser.
I want to do at least two more things before putting togther an NPackage version 1.0 release:
- Packages should be able to depend on other packages. These dependencies should consist of a package name and, optionally, the range of version numbers that are acceptable. NPackage will pick the latest version of each package that satisfies all the version number constraints.
- Developers should be able to set up a local package repository that takes prececdence over the web site
Hopefully I'll at least have dependencies working by next weekend.
Are you familiar with Artifactory? Can you compare and contrast Artifactory vs. NPackage?
Cheers,
Daniel
I want the barrier for adoption of NPackage to be as low as possible:
* For application developers, I want to make it as straightforward as possible to pull in third-party libraries. This means having a robust client app and a repository that's pre-populated with most of the libraries you're likely to need.
* Likewise for application developers, I want to make it as straightforward as possible to share code. This means putting as few constraints as possible on what you submit; having a repository that's smart enough to figure out metadata based on the structure of your library; and being able to easily run your own mini-repository for testing.
I guess I see NPackage as being the DVCS of package management systems, if you compare systems like Artifactory to centralised source control.