Propose replacing specs (e.g. ckan://{name} and replaing with full urls.
Why: specs are confusing to most users and urls are directly copy-able and past-able.
Problems: Requires some intelligent inference about the type of url provided (is it ckan or a local file or ...)
What commands take specs:
- download (will be renamed to clone or install depending on situation):
- For source will take url and always assume it is CKAN
- For dest we assume this is path on disk (or if absent, default install location)
- register: give up on bi-directional registration and always assume that source is local and dest is url
- search: trickier. suggest defaulting this to a value set in config file and possibly allowing for a --catalog or --repository option
- info: switch on whether path or url and assume url indicates ckan and path indicates local path (how do we deal with our local index / repo??)
Current specs
A "spec" is a string identifying a package within a package index (or, sometimes, just the index).
It therefore combines index/repository information with an identifier for that package within the index. It is directly based on URIs.
Spec strings start with as 'scheme' part identifying the type of index and then have additional information used to specify the package (and perhaps the index). For example, for the 3 types of index currently available::
ckan://{package-name}
file://{index-path}/{package-name}
db://{packag-name}
Examples::
ckan://dpmdemo # dpmdemo package in the CKAN index
file:///some/path/on/disk
file://. # current directory
file://./xyz # relative path xyz from the current directory
db://dpmdemo # dpmdemo in the (local) database index
For the convenience of users we also support a default index (set in the config file). This allows one to simply use the package identifier for the spec, e.g.::
Propose replacing specs (e.g. ckan://{name} and replaing with full urls.
Why: specs are confusing to most users and urls are directly copy-able and past-able.
Problems: Requires some intelligent inference about the type of url provided (is it ckan or a local file or ...)
What commands take specs:
Current specs
A "spec" is a string identifying a package within a package index (or, sometimes, just the index).
It therefore combines index/repository information with an identifier for that package within the index. It is directly based on URIs.
Spec strings start with as 'scheme' part identifying the type of index and then have additional information used to specify the package (and perhaps the index). For example, for the 3 types of index currently available::
Examples::
For the convenience of users we also support a default index (set in the config file). This allows one to simply use the package identifier for the spec, e.g.::