Raise warnings instead of errors

[myitcv]

Creating a discussion following an exchange with @kghenderson on Slack.

Original question/statement:

i wish there was a 'warn' facility to non-break but still return errors: e.g. for object names and api might allow (almost) any string of any length, but we want to have and be warned if a regex breaks, e.g. [_a-z][_a-z0-9]

maybe this involves being able to switch out packages or strictness, but we're trying to build a glidepath between allowing what say a database will allow versus a teams best practices which we gradually want to enforce

[myitcv]

This is an interesting use case.

Presumably you have a "base" schema that cannot be violated in any way.

Then on top of that, those constraints that you would like to consider warnings?

You could do something like this today with build constraints, e.g.

# See cuelang.org/issue/2104 for explanation on why we
# need to list all package CUE files here.

# Base validation
exec cue vet -d '#Person' joe.json base.cue warnings.cue

# Warnings-based validation
! exec cue vet -t warnings -d '#Person' joe.json base.cue warnings.cue
cmp stderr stderr.golden

-- base.cue --
package x

#Person: {
	Name: string
	Age:  int
}
-- cue.mod/module.cue --
module: "mod.com/x"
-- joe.json --
{
	"Name": "Joe-Happy Person",
	"Age": 99
}
-- warnings.cue --
@if(warnings)

package x

#Person: Name: "^[a-zA-Z ]+$"
-- stderr.golden --
Name: conflicting values "^[a-zA-Z ]+$" and "Joe-Happy Person":
    ./joe.json:2:10
    ./warnings.cue:5:16

[myitcv]

Further response from @kghenderson:

thank you for the example here, i know it's possible to merge/unify with additional constraints (which is great), but ideally we could also work them into the same package for simplicity

let's say that postgres will allow you to name a table pretty much anything, including with unicode, but just no line breaks and under 512 characters (oversimplifying here) and maybe some tables currently do have wingdings, emoticons or umlauts or spaces or something, it's a reality ...

but what we might want (per team) is starts with a table type prefix (enum), all lowercase, no spaces, ascii only, and max of 40 chars (e.g. max width of a drop-down)

i'd rather have my team prefix inherit from the common postgres baseline, and import just my own as the definition, e.g. TableName: postgres.tableName & ... some other team constraints (not valid syntax of course)

it should still validate, because we can't reject what we have, but we should receive warnings and work towards a gradual cleanup, and then start to tighten/lock down the constraints in that model so once they're gone they can switch to not being allowed (possibly even having a bypass, but that would effectively just be using a different definition)

obviously there's more thinking to do, but i don't love that the users would have to this, versus me as a the project/schema administrator doing this (but it's a long-term thought, not a blocking requirement)

as such, i've just build some external scripts/tools that do this checking and spit out a report

[myitcv]

I think your intuition is right: this belongs in the tooling layer, rather than as a core language construct.

i.e. given my example above, with the "right" tooling, the errors reported in the second cue vet could be reported as warnings. That would require a Go program/cue cmd script to implement.

That tooling would also be responsible for working out how to fetch and combine the policy that represents the base schema and the policy that represents the warnings.