Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update compiler to consume local imports #2116

Merged
merged 1 commit into from
Nov 6, 2024

Conversation

tstirrat15
Copy link
Contributor

Description

Part of getting composable schemas implemented. This actually implements the traversal.

Notes

This is intentionally incremental, and is not intended to be the release candidate. Future work includes:

  • Import cycle tracking
  • Only including requested imports (rather than all imports)

Changes

  • Plumb an existingNames value through the compiler so that it can track the definitions it's already seen
  • Add file importer logic
  • Implement import logic the translator

Testing

Review. See that tests go green.

@tstirrat15 tstirrat15 force-pushed the update-compiler-to-consume-imports branch from ae9d114 to 8946248 Compare November 4, 2024 19:57
@github-actions github-actions bot added the area/tooling Affects the dev or user toolchain (e.g. tests, ci, build tools) label Nov 4, 2024
Copy link
Contributor Author

@tstirrat15 tstirrat15 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A couple of thoughts

existingNames []string
// In an import context, this is the folder containing
// the importing schema (as opposed to imported schemas)
sourceFolder string
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't really like how I need to plumb this through three levels in order to get it to the next compilation context. I'd welcome recommendations on a different way to structure this.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why can't you put it on the translationContext?

@@ -22,6 +23,8 @@ type translationContext struct {
mapper input.PositionMapper
schemaString string
skipValidate bool
existingNames []string
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this be a *mapz.Set up and down the stack?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Likely

@tstirrat15 tstirrat15 force-pushed the update-compiler-to-consume-imports branch from 0653113 to 775de22 Compare November 5, 2024 17:51
@tstirrat15 tstirrat15 marked this pull request as ready for review November 5, 2024 17:51
@tstirrat15 tstirrat15 requested a review from a team as a code owner November 5, 2024 17:51
existingNames []string
// In an import context, this is the folder containing
// the importing schema (as opposed to imported schemas)
sourceFolder string
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why can't you put it on the translationContext?

// TODO: do we want this sort of logging here?
log.Trace().Str("schema", string(schemaBytes)).Str("file", filepath).Msg("read schema from file")

compiled, err := Compile(InputSchema{
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you call an internal compile, then this could be passed the translationContext directly and then you wouldn't need a different context here or the need to pass it into Compile


func ImportFile(importContext *ImportContext) (*CompiledSchema, error) {
relativeFilepath := constructFilePath(importContext.pathSegments)
filePath := path.Join(importContext.sourceFolder, relativeFilepath)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what happens if the imports are outside of the root context folder? is that supported, and if not, what kind of opinions/guidelines does it impose on the structure of a composable schema?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No; the eventual goal will be to support this using git-based imports

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The biggest effect that I see is that you won't be able to do a relative import within the package that walks up a directory. this means that you couldn't have:

app1/app1.zed
app2/app2.zed
util.zed

and have both app files reference the util file. I have a feeling this will be a tripping point; it'll either have to be well-documented or something we change.

@@ -1,6 +1,6 @@
---
name: "Lint"
on: # yamllint disable-line rule:truthy
on: # yamllint disable-line rule:truthy
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why this change and below?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yamllint wants two spaces before an inline comment and appeared to be failing the lint check as a result.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Blech


const SchemaFileSuffix = ".zed"

func ImportFile(importContext *ImportContext) (*CompiledSchema, error) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unless you see a need to export this, should we just keep this internal (i.e. lowercase)?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That works for me

@tstirrat15 tstirrat15 force-pushed the update-compiler-to-consume-imports branch from 85172fc to 66f9d26 Compare November 6, 2024 15:35
@@ -68,12 +72,21 @@ func AllowUnprefixedObjectType() ObjectPrefixOption {
return func(cfg *config) { cfg.objectTypePrefix = new(string) }
}

func SourceFolder(sourceFolder string) Option {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Add a doc comment explaining what this does. Probably good to add doc comments to the other exported functions too

"github.com/authzed/spicedb/pkg/genutil/mapz"
)

type ImportContext struct {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

make this context unexported as well


const SchemaFileSuffix = ".zed"

func importFile(importContext *ImportContext) (*CompiledSchema, error) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why does this take in a * vs just the importContext struct itself?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Mostly me not having built an intuition yet for when you would use one vs the other.

return nil, fmt.Errorf("failed to read schema file: %w", err)
}
// TODO: do we want this sort of logging here?
log.Trace().Str("schema", string(schemaBytes)).Str("file", filePath).Msg("read schema from file")
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes; trace is good

log.Trace().Str("schema", string(schemaBytes)).Str("file", filePath).Msg("read schema from file")

compiled, err := compileImpl(InputSchema{
// TODO: should this point to the schema file? What is this for?
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes; it gives the file path for error messaging

@tstirrat15 tstirrat15 force-pushed the update-compiler-to-consume-imports branch from 80aa245 to 6cba14f Compare November 6, 2024 17:53
Copy link
Member

@josephschorr josephschorr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@tstirrat15 tstirrat15 force-pushed the update-compiler-to-consume-imports branch from 6cba14f to f8ceb8e Compare November 6, 2024 18:03
@tstirrat15 tstirrat15 added this pull request to the merge queue Nov 6, 2024
@github-merge-queue github-merge-queue bot removed this pull request from the merge queue due to failed status checks Nov 6, 2024
@tstirrat15 tstirrat15 added this pull request to the merge queue Nov 6, 2024
@github-merge-queue github-merge-queue bot removed this pull request from the merge queue due to failed status checks Nov 6, 2024
@tstirrat15 tstirrat15 added this pull request to the merge queue Nov 6, 2024
Merged via the queue into main with commit 20f450c Nov 6, 2024
22 checks passed
@tstirrat15 tstirrat15 deleted the update-compiler-to-consume-imports branch November 6, 2024 19:00
@github-actions github-actions bot locked and limited conversation to collaborators Nov 6, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
area/tooling Affects the dev or user toolchain (e.g. tests, ci, build tools)
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants