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

lexgen runs all packages together #709

Merged
merged 1 commit into from
Jul 31, 2024
Merged

Conversation

brianolson
Copy link
Contributor

cross-package references can now make a type know that it needs to include a type field

cross-package references can now make a type know that it needs to include a type field
Copy link
Collaborator

@bnewbold bnewbold left a comment

Choose a reason for hiding this comment

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

I ran this branch against the atproto repo main branch and the output looks good/expected to me.

Left some notes about flexibility with the lexgen tool with 3rd party lexicons, which hasn't been taken advantage of much to date, but probably will be soon (coming weeks). I can take adding an additional entrypint / sub-command for that use-case when it is needed.

I only skimmed the actual code changes, assuming that @ericvolp12 or @whyrusleeping will review code quality.

Comment on lines +1483 to +1488
var Packages []Package = []Package{
Package{"bsky", "app.bsky", "api/bsky"},
Package{"atproto", "com.atproto", "api/atproto"},
Package{"chat", "chat.bsky", "api/chat"},
Package{"ozone", "tools.ozone", "api/ozone"},
}
Copy link
Collaborator

Choose a reason for hiding this comment

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

in the near-ish future we are going to want to make it easy for folks to use this tooling for non-bluesky-maintained lexicons (aka, independent lexicons).

in the medium-term, it is most likely that any inter-namespace references would be from independent lexicons to one of these lexicons (aka, independent lexicons referencing com.atproto.* or app.bsky.actor.profile). so having these hard-coded in is fine.

overall I think having these hard-coded is fine for this PR, but I would guess we might want an additional command more like the previous behavior soon (coming weeks).

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'd replace this (and the go imports package paths) with a json/yaml config input to lexgen

Comment on lines +54 to +56
prefix string // prefix of a major package being processed, e.g. com.atproto
id string // parent Schema.ID
defName string // parent Schema.Defs[defName] points to this *TypeSchema
Copy link
Collaborator

Choose a reason for hiding this comment

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

comments 💪 !

@ericvolp12
Copy link
Collaborator

Confirming on my end that the changes to lexicons that I see when running lexgen from this branch look good (just out of date/stale stuff that hasn't been needed on the Go side of things yet). I figure you're gonna merge this and then open another PR with the updated lexicons and requisite changes to make stuff build?

Also I do agree with @bnewbold that it may be best to pass the packages into the Run() entrypoint in lex/gen.go rather than have them hardcoded inside that file. Should be totally fine to define those in cmd/lexgen as a default value somewhere that users can override with a CLI flag or something.

@brianolson brianolson merged commit 2ca57ad into main Jul 31, 2024
7 checks passed
@brianolson brianolson deleted the bolson/lexgen-alltogether branch July 31, 2024 06:35
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants