Initial implementation

[pwalsh]

Also ref: frictionlessdata/datapackage-py#1

This is essentially a take on datapackage-init that has no relation to a file system at all, and really focusses on building out the datapackage.json descriptor (which can be output from the model using https://github.com/okfn/datapackage-outfile-js).

In the future, we may refactor datapackage-init to work with this behind the scenes. For now, we develop this standalone in order to work comfortably with datapackages as we build them up from user data, in the browser, or in Node without the expectation of a local directory that represents a data package.

[rufuspollock]

@pwalsh given name i'm wondering about just merging this with dpm ... - dpm already "owns" datapackage in npm registry and it is the logical place for putting a primary "Data Package" node library.

Aside: if this is "datapackage-init"-lite might it not be worth merging with datapackage-init esp given openknowledge-archive/datapackage-init-js#2

Also: https://github.com/frictionlessdata/datapackage-render-js/blob/master/datapackage.js is looking for a home and i was thinking of dpm/datapackage-js ...

[pwalsh]

@rgrp the purpose here is very different IMHO. We need a core lib that provides a model for working with DPs that is not tied to Node FS (like datapackage-init). I'd imagine this lib would then be used to refactor the init lib, and maybe others. DPM does so much more stuff than what this would do, which I imagine would be an issue for use of DPM in the browser to model DPs.

[rufuspollock]

@pwalsh ok but how will that work and what would that "core model" do beyond being a trivial skeleton? The moment you add any functionality (e.g. serialize / unserialize) you will start looking quite complex (based on my experience so far).

Maybe best way is to write out some of the methods that DataPackage object and sub-objects (e.g. Resource) will have.

BTW: should some of this https://github.com/frictionlessdata/datapackage-render-js/blob/master/datapackage.js merge in here?

[pwalsh]

Yes, I think parts of your render lib for handling DP should go here.

The best reference for methods IMHO is the Python lib: https://github.com/frictionlessdata/datapackage-py

[rufuspollock]

@pwalsh but once you have those methods (i.e. datapackage-py) you have a pretty heavy library and so what is the difference with current dpm / datapackage?

I understand you say you don't want tied to nodejs but if you want create method to work with a filesystem or with a url (ala datapackage-py) you pretty much need nodejs.

[rufuspollock]

@pwalsh did you see my comment back in May?

Also want to flag the name conflict with dpm so you can think about a resolution :-)

This latter is important since e.g. if we factor stuff out of datapackage-render-js it needs to depend on a node lib and it needs a name etc etc. My suggestion would be to have dpm move to datapackagemanager or something (sort of ugly but hey) and have this lib take over for datapackage in npm. Alternatives are using datapkg but that is pretty confusing (having datapkg and datapackage)

[pwalsh]

@rgrp I forgot about this comment. Seems to me that dpm still has a larger scope than this, but I'll look again in more detail over the coming week.

[roll]

CLOSED in favor of #7