-
Notifications
You must be signed in to change notification settings - Fork 275
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
Implement SPICE-0009 External Readers #660
base: main
Are you sure you want to change the base?
Conversation
337ab5a
to
9d8a587
Compare
f6d8810
to
19bc962
Compare
a935e9d
to
9251522
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.
Did a first pass.
This is looking pretty good! Looks pretty polished, with just a couple of issues.
Design question: what do we want to do about env vars or CWD of the process?
What should users expect if thay do:
pkl --env-var foo=bar --external-module-reader ldap=my-ldap-reader
Should my-ldap-reader
receive foo=bar
as an env var? Or should there be some way to configure the env vars that get passed to this reader?
Same question applies for --working-dir
.
Thoughts: probably not appropriate to pass these values into the process, but it should be clearly documented. But, we should probably have some way to configure env var, as well as CWD for these processes.
pkl-commons-cli/src/main/kotlin/org/pkl/commons/cli/commands/BaseOptions.kt
Show resolved
Hide resolved
pkl-core/src/main/java/org/pkl/core/externalProcess/ExternalProcessImpl.java
Outdated
Show resolved
Hide resolved
@@ -226,6 +256,9 @@ class Server(private val transport: MessageTransport) : AutoCloseable { | |||
if (message.clientModuleReaders?.isNotEmpty() == true) { | |||
add(ClientModuleKeyFactory(message.clientModuleReaders, transport, evaluatorId)) | |||
} | |||
for ((scheme, spec) in message.externalModuleReaders ?: emptyMap()) { | |||
add(ModuleKeyFactories.external(scheme, getExternalProcess(evaluatorId, spec), evaluatorId)) |
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.
Do these external readers ever need to care about what the evaluator ID is?
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.
Not really, since the MessageTransport
is distinct from the server's. One reason to still populate this is PKL_DEBUG
logging. Because the message contents are printed, this could help debug issues in multi-evaluator scenarios.
4fc48da
to
98ec98f
Compare
This is preparatory work for [SPICE-0009](apple/pkl-evolution#10). It is being contributed in a separate pull request to ease review. The Message, Message(En|De)coder, and MessageTransport types have been ported to Java and moved to a new `org.pkl.core.messaging` package.
9d35221
to
97313c9
Compare
[SPICE-0009](apple/pkl-evolution#10) New close flow
97313c9
to
9323690
Compare
Box Bytes, fix error CLI handling during project load Bytes equals compare
Co-authored-by: Daniel Chao <daniel.h.chao@gmail.com> Apply suggestions from code review Co-authored-by: Daniel Chao <daniel.h.chao@gmail.com> Rename --external-* CLI flags to --external-*-reader Rename ExternalProcess -> ExternalReaderProcess Add org.pkl.core.util.Readers.closeQuietly and deprecate ModuleReaders.closeQuietly Clean up doc comments Refactor ExternalReaderRuntime into pkl-config-java Refactor out External*Resolver classes, rename ResourceReaders.ExternalDelegate and ModuleKeys.External to MessageTransport
9323690
to
e561cc3
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.
One more pass. Getting close!
pkl-core/src/main/java/org/pkl/core/module/ModuleKeyFactories.java
Outdated
Show resolved
Hide resolved
pkl-config-java/src/main/java/org/pkl/config/java/ExternalReaderRuntime.java
Outdated
Show resolved
Hide resolved
pkl-core/src/main/java/org/pkl/core/externalReader/package-info.java
Outdated
Show resolved
Hide resolved
@@ -771,4 +777,56 @@ public boolean hasElement(SecurityManager securityManager, URI elementUri) | |||
return projectResolver.getResolvedDependenciesForPackage(packageUri, dependencyMetadata); | |||
} | |||
} | |||
|
|||
public static class MessageTransport implements ModuleKey { |
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.
public static class MessageTransport implements ModuleKey { | |
public static class External implements ModuleKey { |
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.
Hmm, I had renamed this to align with ResourceReaders.MessageTransport
since, like that class, this one is used by both external readers and client readers. I think I'd prefer to keep this name and preserve the symmetry. Thoughts?
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.
Ooh I see.
Maybe ResourceReaders.ExternalResolver
?
And then call the other one ResourceReaders.ExternalProcess
?
And then apply the same names on the module side?
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.
Done! I also moved the External*Resolver
classes into the module
/resource
packages since they're not specific to the external reader stuff. I can also see reason for putting these in messaging
, so let me know if you'd prefer that.
pkl-core/src/main/java/org/pkl/core/resource/ResourceReaders.java
Outdated
Show resolved
Hide resolved
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.
Overall LGTM! Great work!
This also needs eyes from @holzensp @stackoverflow because it touches the core language.
…al resolvers into module/resource packages
SPICE-0009
Includes the changes from #640
Adoption of this feature in language binding libraries: