Pain Point: Published vs Local schemas

[discount-elf]

Has any thought been given regarding the following:

We have a problem that makes development and the shipping of schemas with an app that cannot reach out to the internet difficult to deal with, essentially it requires us to touch the Pklproject file to update the import locations depending on the use case, or in the case of a custom uri scheme to load an embedded schema losing type validation in an IDE when editing documents that import or amend it.

A solution that could resolve this is more elegantly could be:
fallbackUri: file://some/local/path

pkl project resolve could then resolve the dependency from the fallback uri, in the event of a 404 or failure of the primary uri.

[HT154]

There are a few viable solutions for air-gapping Pkl evaluation, depending on the precise requirements. We have a blog post outlining the techniques available today: https://pkl-lang.org/blog/using-packages-in-air-gapped-environments.html

Do any of these techniques work for your use case?

[discount-elf]

We can make it work, but it's ugly for the user when shipping an app that depends on Pkl, and the expectation is that the syntax support will work in the IDE with messing about with the project or settings file :/

[bioball]

If your package schema evolves with your application and is bundled together, you can use a local dependency to describe this, see https://pkl-lang.org/main/current/language-reference/index.html#local-dependencies

If you need to use packages that are published to the internet, another approach is that you can also vendor the dependencies directly inside your project; what that looks like is to set a module cache dir to a project-local location, and to configure your evaluator accordingly (see https://pkl-lang.org/blog/using-packages-in-air-gapped-environments.html#vendoring-dependencies)