For reference, here are items Node considers to be a package:
a) a folder containing a program described by a package.json file b) a gzipped tarball containing (a) c) a url that resolves to (b) d) a <name>@<version> that is published on the registry with (c) e) a <name>@<tag> that points to (d) f) a <name> that has a "latest" tag satisfying (e) g) a git url that, when cloned, results in (a).
We don't have to exactly copy what they've done but I've been thinking about a generic thing called registries (or perhaps repositories) that you can register with CommandBox. They would abstract away "some remote place where packages could be located". Allow a registry definition to be installed (preferably like a command from ForgeBox) and then the user can create instances and override default settings. A registry would implement an CFML Interface IRegistry.cfc for checking on the existence of a package and retrieving it (and possibly contributing back). There could be one that worked on the local filesystem one for a remote HTTP-based artifacts repo, one for forgebox, one for GitHub, etc.
The current (forgebox) install command would be converted into a compliant registry and when using the generic "install" command, CommandBox would search through the registries until it found one that could satisfy the package being asked for. By the way, this ticket would presuppose the existence of a global settings file for CommandBox like we've talked about but never really implemented yet.
Node does something similar. For instance, if you try "install foo" and you have a local folder called "foo" it will try to install that first before looking in the online NPM registry. I don't think NPM allows you to create adapters though to make anything a registry.
This is a generic ticket to support additional installation types. We can create subtasks or related tickets for each piece.
Gliffy Diagrams
Activity
Show:
Brad Wood August 7, 2015 at 5:46 PM
This was broken out into separate tickets and is mostly complete. I'll close this one now.
Fixed
Pinned fields
Click on the next to a field label to start pinning.
For reference, here are items Node considers to be a package:
We don't have to exactly copy what they've done but I've been thinking about a generic thing called registries (or perhaps repositories) that you can register with CommandBox. They would abstract away "some remote place where packages could be located". Allow a registry definition to be installed (preferably like a command from ForgeBox) and then the user can create instances and override default settings. A registry would implement an CFML Interface IRegistry.cfc for checking on the existence of a package and retrieving it (and possibly contributing back). There could be one that worked on the local filesystem one for a remote HTTP-based artifacts repo, one for forgebox, one for GitHub, etc.
The current (forgebox) install command would be converted into a compliant registry and when using the generic "install" command, CommandBox would search through the registries until it found one that could satisfy the package being asked for.
By the way, this ticket would presuppose the existence of a global settings file for CommandBox like we've talked about but never really implemented yet.
Node does something similar. For instance, if you try "install foo" and you have a local folder called "foo" it will try to install that first before looking in the online NPM registry. I don't think NPM allows you to create adapters though to make anything a registry.
This is a generic ticket to support additional installation types. We can create subtasks or related tickets for each piece.