Disable profile stuff by default

frictionlessdata / datapackage-js

A JavaScript library for working with Data Package.

http://frictionlessdata.io/

MIT License

43 stars 15 forks source link

Disable profile stuff by default #45

Closed rufuspollock closed 7 years ago

rufuspollock commented 7 years ago

Profile is used quite rarely IME and it results in automatic http calls (which is annoying if working locally offline).

Could we consider having profile support off by default?

roll commented 7 years ago

We will achive it in https://github.com/frictionlessdata/datapackage-js/issues/43

rufuspollock commented 7 years ago

@roll i'm not quite sure #43 this is the same thing. Simple disabling is different from bundling. Bundling results in a whole bunch of issues (e.g. bundled schema can go out of date etc).

roll commented 7 years ago

@rufuspollock What do you mean by disable profile - disable validation? Or just have base profile?

rufuspollock commented 7 years ago

@roll 2 options:

disable validation by default - if i want to do that then i need the profile (or rather just validate you have valid json)
or just have base and bundle that in

The key thing is that we have to be able to run offline and without http calls from the lib ...

roll commented 7 years ago

@rufuspollock Thanks. We will support 100% offline (as a user story) no doubts.

pwalsh commented 7 years ago

just a note:

yes, 100% offline support, by building in the schemas (same as python lib)
no, not actually disabling validation - will always be possible to validate against the base dp schema

rufuspollock commented 7 years ago

@pwalsh i note the problem of getting out of date with schemas but happy to go with built in (and you can't build all in, right ...?)

For me, right now it is just a question of getting MVP asap ;-) - for my use generic profile support is not on that MVP

pwalsh commented 7 years ago

so in that case, you are not blocked now that https works in schemas.frictionlessdata.io. it will be nice to not have the http requests for the schemas, but it does not block any mvp functionality while the lib still makes those requests.

roll commented 7 years ago

@rufuspollock Every version of jsontableschema/datapackage is packaged with some version of schemas. So e.g. if you use datapackage@1.2.3 you use builtin for instance datapackage-profile@1.2-rc4. So it can't be outdated it's just a characteristic of concrete package version. To update to new datapackage-profile schema a client should update datapackage package itself. I would say it's a good way to handle it because of the predictability to clients (strict map between datapackage version -> schemas versions).

Also we're injecting mechanism across libs to be sure we're releasing with the latest version of schemas (otherwise tests just fail).