-
Notifications
You must be signed in to change notification settings - Fork 247
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
Modules support relative path 2 #1726
Conversation
7bdd35b
to
69b8022
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this go through a proposal as a user-facing API?
I think there are different ways to design this that we'd want to consider before implementing.
Another idea, which I think could be powerful and simple for users to work with: if a file has a relative path in it, it is relative to that file's location. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A few small comments, but LGTM in general.
Before merging, would it make sense to share it with someone who uses modules extensively to test this build? Or check if it works with fleet management?
@bentonam would be a good candidate |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would like to see vm.Scope
to have a constructor, but otherwise LGTM.
internal/runtime/alloy.go
Outdated
ComponentBlocks: source.components, | ||
ConfigBlocks: source.configBlocks, | ||
DeclareBlocks: source.declareBlocks, | ||
ArgScope: &vm.Scope{ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What are the rules for the vm.Scope
now? Does it always need to have either a Parent or ModulePath set?
I think the way it's instantiated now is error-prone. I would prefer to have specialised constructors in vm
package that enforce correct creation of vm.Scope
so that we don't make mistakes or have semantic merge conflicts that result in bugs.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
added via d543652
Co-authored-by: Clayton Cornell <131809008+clayton-cornell@users.noreply.github.com>
f2c018c
to
72440bd
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks OK in a local build. I may open a new PR to change the way we present the main.alloy
, lib.alloy
, etc. code blocks, but... it's good enough as it is right now for this PR.
Co-authored-by: Clayton Cornell <131809008+clayton-cornell@users.noreply.github.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
…alloy into modules-support-relative-path-2
PR Description
This PR introduces an ArgScope to the loader that will be used as a parent scope when evaluating the nodes in the module. For now, it contains only one variable "module_path" that represents the current path of the module and can be used in the config. Both can be used together to configure a relative path on the import.file block.
The following use-cases are currently supported:
import.file in a module imported via import.file (module_path = filename of the parent import.file)
import.file in a module imported via import.git (module_path = path to the local cloned repo)
import.file in a module imported via import.string (module_path = path of the current module)
Which issue(s) this PR fixes
Fixes #786
Notes to the Reviewer
This was an old PR that I revived now that the stdlib has been updated.
I recommend reviewing commit by commit.
PR Checklist