Closed rufuspollock closed 7 years ago
We will achive it in https://github.com/frictionlessdata/datapackage-js/issues/43
@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).
@rufuspollock
What do you mean by disable profile
- disable validation? Or just have base profile?
@roll 2 options:
The key thing is that we have to be able to run offline and without http calls from the lib ...
@rufuspollock Thanks. We will support 100% offline (as a user story) no doubts.
just a note:
@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
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.
@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).
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?