Module system extensions and assemblies #12
Conversation
|
|
||
| ### Foreign formats | ||
|
|
||
| `import` can be used to import objects defined in other CAD formats, replacing the `import` function in the standard library. E.g., `model = import("tests/inputs/cube.obj")` is replaced by `import "tests/inputs/cube.obj" as model`. Such objects are treated in the same way as other assemblies, but they are always opaque (no AST, etc.) and read-only. |
There was a problem hiding this comment.
I was wondering about this. I like the idea of combining these cases.
|
|
||
| This is mostly postponed for future work. We would use the same syntax and semantics as the rest of the system, however the string in the import would include some indicator that the target is outside the project and how to locate it. | ||
|
|
||
| Example with very, very strawman syntax: `import a from "cargo://some-library/foo.kcl"` would import `a` from the file `foo.kcl` in the project `some-library` located in the `cargo` (lol) repository. `import a from "local://../some-library/foo.kcl` would import `a` from the file `foo.kcl` from a sibling directory of the current project called `some-library`. The point of these examples is not the syntax for identifying other projects or the places where an external project might live, just to show how the `import` statement might be extended to support other projects. |
There was a problem hiding this comment.
Interesting. I hadn't seen anything like this before.
There was a problem hiding this comment.
We should properly design the syntax inside the quotes here, I literally just made it up, but I'm sure we can figure something out which does everything we need it to, whether that's url-like or more structured or whatever
|
|
||
| This is mostly postponed for future work. We would use the same syntax and semantics as the rest of the system, however the string in the import would include some indicator that the target is outside the project and how to locate it. | ||
|
|
||
| Example with very, very strawman syntax: `import a from "cargo://some-library/foo.kcl"` would import `a` from the file `foo.kcl` in the project `some-library` located in the `cargo` (lol) repository. `import a from "local://../some-library/foo.kcl` would import `a` from the file `foo.kcl` from a sibling directory of the current project called `some-library`. The point of these examples is not the syntax for identifying other projects or the places where an external project might live, just to show how the `import` statement might be extended to support other projects. |
There was a problem hiding this comment.
There was a problem hiding this comment.
strong concur; it also lets us avoid the incredible complexity of a package manager (and associated tooling which we'd have to handle), as well as it adds a lot of clarity in the modules (no namespace squatting; food-fight adjudication over copyrights and shit.
It also gives a level of "official" status to our repos and other trusted orgs -- it's hard to tell if https://pypi.org/project/cryptography/ is official pyca or some rano without looking closely; or like tokio_xyz -- is that tokio or some rando? Hard to tell unless you find the repo (which may or may not get linked).
Love having everything be a git url, or even some intermediate like go's module url protocol if we wanted to get wicked fancy with it (for sub-folder imports this would be required so we know where the module root is; likely with special-casing for github as go-get has until they support ?kcl-import=1)
|
Being able to import from the internet would be very nice for open source projects so that not everything needs to be downloaded locally by the user somehow. Referencing the imported code via by a git commit or tag (e.g. v1.1) can be specified in the URL to ensure getting the intended and stable / locked-down version of the code. |
Signed-off-by: Nick Cameron <nrc@ncameron.org>
This doc describes possible extensions to the current
import/exportsyntax for modules. This includes support for assemblies.