I’m now trying to design an extensible and customizable mechanism for providing non-JS foreign files for alternative backends.
I want to make an index repository called a mirror which can map a pursuit package(like
purescript-prelude) to a GitHub repo which provides FFI files for specific backends.
For instance, I made this repo purescript-prelude.py to provide Python FFI files for purescript-prelude.
However, some problem got raised now:
I cannot track the source of each
foreign.js: I can only know the qualified name of the module a
foreign.js is from, but not the package, or the version of the source package.
If I don’t know where a
foreign.js is from, I still have some approaches to work things out.
The unsolvable problem is I can’t know the package version of a
foreign.js: if the author of a pursuit library uses different JS FFI files, I will fail at providing FFI files for other backends because I can’t know files of which version to provide.
I found a workround to get the version of package: it seems that I can extract the pattern
*/v\d.\d.\d/src/* from the filename.
I wonder if this is robust?
nvrmind, I got it.
I can firstly build the package, and call
spago sources to get all packages with their versions. Then I use external commands to build a directory which accommodates Python FFI files, where later code generation will request FFI files from.
Alternative backends are meant to provide the scheme by which foreign modules are resolved. It may not always be practical to keep some source file next to some purs file. All
corefn.json files (which you’d be using to generate code) however contain a path to the original source
purs file. https://github.com/purescript/purescript/blob/ed130c78b708ff55cf4a80b126a1bd3ba5d80eb9/src/Language/PureScript/CoreFn/Module.hs#L20
Thank you. I’ve found this via @natefaubion 's link, and worked things out