Support Projects loaded from arbitrary URIs #255
Conversation
| @@ -176,7 +183,7 @@ typealias LocalDependency = Project( | |||
| /// 1. Gather all dependencies, both direct and transitive. | |||
| /// 2. For each package's major version, determine the highest declared minor version. | |||
| /// 3. Write each resolved dependency to sibling file `PklProject.deps.json`. | |||
| dependencies: Mapping<String(!contains("/")), *RemoteDependency|LocalDependency> | |||
| dependencies: Mapping<String(!contains("/")), * RemoteDependency|Project(isValidLoadDependency)> | |||
There was a problem hiding this comment.
This works around a bug in typealias resolution that caused the above projectFileUri to return pkl:Project instead of the actual module URI
| if (response.error != null) { | ||
| completeExceptionally(IOException(response.error)) | ||
| } else if (response.pathElements != null) { | ||
| complete(response.pathElements) | ||
| } else { | ||
| completeExceptionally(IOException(response.error)) | ||
| complete(emptyList()) |
There was a problem hiding this comment.
response.pathElements may be null if the client resource reader (eg. in pkl-go) returns an empty/nil slice of PathElements
| is ListModulesResponse -> { | ||
| if (response.error != null) { | ||
| completeExceptionally(IOException(response.error)) | ||
| } else if (response.pathElements != null) { | ||
| complete(response.pathElements) | ||
| } else { | ||
| complete(response.pathElements!!) | ||
| complete(emptyList()) | ||
| } | ||
| } |
There was a problem hiding this comment.
Same here: response.pathElements may be null if the client resource reader (eg. in pkl-go) returns an empty/nil slice of PathElements. This also aligns the implementation with ClientResourceReader.
|
|
||
| // https://github.com/apple/pkl/issues/166 | ||
| // ["glob-import behind local project import"] { | ||
| // import("@project6/children.pkl") | ||
| // } |
There was a problem hiding this comment.
This is a test for #166. I suspected these changes might resolve the issue, but they do not. This change did seem to surface a clearer error though. It looks like when the ImportGlobNode is executed, currentModule has a file: URI while importUri has a projectpackage: URI. This disagreement causes ModuleKeys.ProjectPackage.listElements to eventually bark since it doesn't know about file: URIs.
| /** | ||
| * Used by ResourceReaders.ProjectPackageResource to resolve resources from projects that may not | ||
| * be on the local filesystem | ||
| */ | ||
| public List<PathElement> listElements(URI baseUri) throws IOException, SecurityManagerException { | ||
| var reader = resourceReaders.get(baseUri.getScheme()); | ||
| if (reader == null) { | ||
| throw new VmExceptionBuilder() | ||
| .evalError("noResourceReaderRegistered", baseUri.getScheme()) | ||
| .build(); | ||
| } | ||
|
|
||
| return reader.listElements(securityManager, baseUri); | ||
| } | ||
|
|
||
| /** | ||
| * Used by ResourceReaders.ProjectPackageResource to resolve resources from projects that may not | ||
| * be on the local filesystem | ||
| */ | ||
| public boolean hasElement(URI elementUri) throws IOException, SecurityManagerException { | ||
| var reader = resourceReaders.get(elementUri.getScheme()); | ||
| if (reader == null) { | ||
| throw new VmExceptionBuilder() | ||
| .evalError("noResourceReaderRegistered", elementUri.getScheme()) | ||
| .build(); | ||
| } | ||
|
|
||
| return reader.hasElement(securityManager, elementUri); | ||
| } |
There was a problem hiding this comment.
I am not a huge fan of needing to pipe these through ResourceManager like this. I'm more than open to alternate suggestions on how to handle this
HT154
force-pushed
the
projects-from-any-uri
branch
from
786656b
to
1da08ff
Compare
HT154
force-pushed
the
projects-from-any-uri
branch
2 times, most recently
from
5a12cd5
to
0aafd91
Compare
HT154
force-pushed
the
projects-from-any-uri
branch
from
0aafd91
to
42224c0
Compare
Currently, Pkl assumes that a PklProject file and any declared local dependencies are accessible on the filesystem (i.e. via
file:URIs. For usage of thepklCLI this is sufficient, but for usage of language bindings this presents an obstacle for evaluating Pkl code using projects from sources that are not the filesystem. One compelling use case would be consuming Pkl code using project dependencies from a git repository; usinggo-gitand itsgo-billyfilesystem abstraction, it should be possible to do this completely in-memory. With this change and apple/pkl-go#21 this now works end-to-end.Brief summary of the changes here:
Path projectDirwithURI projectBaseUrithroughoutPklProject.deps.jsonto use resource readerspkl:Projectto accept local dependencies when the scheme and authority are the same, rather than checking forfile:URIs specificallypkl-corefor custom-defined module and resource readerspathElementsinList*Responses