Skip to content

Conversation

@jkroepke
Copy link

@jkroepke jkroepke commented Sep 18, 2025

Because //go:embed does not allow .., it must be defined where the assets are.

The yaml can be used with

import github.com/ua-parser/uap_core

var yamlFile = uap_core.RegexDefinitions

@dgoldstein0
Copy link
Contributor

(I'm not a uap-core maintainer, so can't approve this PR). Right now the way this works for uap-go is that we have uap-core as a git submodule and manually run our ./build.sh script which updates the submodule & copies the yaml into a .go file in this repo. Is the idea to simplify that somehow?

@jkroepke
Copy link
Author

Yeah. No submodule needed. No build.sh, no source file with inline yaml data. All manual tasks/scripts can be removed in favor of a go native solution.

@dgoldstein0
Copy link
Contributor

Sounds nice. Would that mean users of uap-go could use new uap-core regexes without a uap-go update? That would certainly be nice. (though we've also had the occasional case of newer regexes revealing bugs in uap-go so it's not without risks)

@jkroepke
Copy link
Author

Sounds nice. Would that mean users of uap-go could use new uap-core regexes without a uap-go update?

Yes, uap-core would be a separate Go module with its own lifecycle. Go also supports versionless imports based on Git commit references. Taking it one step further, you could even remove the "default" YAML data from uap-go, making it the end user’s responsibility to choose which version of the data they want to use. That would also be possible while keeping the default YAML, but then the YAML data would be bundled twice (default version + user version), which could unnecessarily bloat the application size.

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.

2 participants