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

Implement SPICE-0009 External Readers #660

Open
wants to merge 12 commits into
base: main
Choose a base branch
from

Conversation

HT154
Copy link
Contributor

@HT154 HT154 commented Sep 23, 2024

SPICE-0009

Includes the changes from #640

Adoption of this feature in language binding libraries:

@HT154 HT154 force-pushed the external-readers branch 4 times, most recently from 337ab5a to 9d8a587 Compare September 24, 2024 15:53
@HT154 HT154 force-pushed the external-readers branch 2 times, most recently from f6d8810 to 19bc962 Compare October 3, 2024 03:54
@HT154 HT154 marked this pull request as ready for review October 3, 2024 03:57
@HT154 HT154 mentioned this pull request Oct 6, 2024
@HT154 HT154 force-pushed the external-readers branch 9 times, most recently from a935e9d to 9251522 Compare October 11, 2024 05:50
Copy link
Contributor

@bioball bioball left a 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/src/main/kotlin/org/pkl/commons/Strings.kt Outdated Show resolved Hide resolved
pkl-commons/src/main/kotlin/org/pkl/commons/Strings.kt 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))
Copy link
Contributor

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?

Copy link
Contributor Author

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.

stdlib/EvaluatorSettings.pkl Outdated Show resolved Hide resolved
stdlib/EvaluatorSettings.pkl Show resolved Hide resolved
stdlib/EvaluatorSettings.pkl Outdated Show resolved Hide resolved
stdlib/EvaluatorSettings.pkl Show resolved Hide resolved
@HT154 HT154 force-pushed the external-readers branch 3 times, most recently from 4fc48da to 98ec98f Compare October 16, 2024 00:35
@HT154 HT154 requested a review from bioball October 16, 2024 00:39
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.
@HT154 HT154 force-pushed the external-readers branch 2 times, most recently from 9d35221 to 97313c9 Compare October 17, 2024 20:22
HT154 and others added 2 commits October 17, 2024 13:32
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
Copy link
Contributor

@bioball bioball left a 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/messaging/Message.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 {
Copy link
Contributor

Choose a reason for hiding this comment

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

Suggested change
public static class MessageTransport implements ModuleKey {
public static class External implements ModuleKey {

Copy link
Contributor Author

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?

Copy link
Contributor

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?

Copy link
Contributor Author

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/module/ModuleKeys.java Outdated Show resolved Hide resolved
stdlib/EvaluatorSettings.pkl Show resolved Hide resolved
@HT154 HT154 requested a review from bioball October 18, 2024 06:36
Copy link
Contributor

@bioball bioball left a 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.

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