Nino
(Gravity Express)
March 11, 2023, 1:06pm
6
Yep, there are some problems around the import statement.
To be most safe, it is best to keep all lua files in a single folder.
I myself opted to implement my own version of the import statement, but you have to know what the pitfalls are when going that route
Interesting reads:
That's what it should be doing--I patched the Lua compiler so that import statements resolve the file and replace the given path with the full project-relative path--but I must have goofed something up. But I expect it'll be easy to reproduce with your test case and hopefully not too terrible to fix.
Unless I'm mistaken, all paths given to the import statement are relative to the file's location.
I'm putting together a little dependency management system for Playdate and it would make cross-dependencies a lot easier if we could also use paths relative to the project root folder. Syntax could be simply something like:
import '/source/test.lua'
which would convert to <Path to the Project Folder>/source/test.lua.
Another way to solve this would be to add include paths support for pdc but it…
With pdc, using the same Lua file, placed in two different locations relative to the current Lua file, this works:
import 'toyboxes/toyboxes' -- WORKS!
while this doesn't find the file:
import '../toyboxes/toyboxes' -- DOESN'T WORK
but this does:
import '../toyboxes/toyboxes.lua' -- WORKS!
Ditching the import statement to improve boot times
As per the docs, the import statement is a function available in the Playdate SDK that is not part of standard Lua. Conversely, the require statement is in every Lua distribution except for Playdate. The import statements are not run by the playdate, but instead by the pdc compiler. import "otherfile" basically means: read otherfile.lua and paste everything you find there at the current position in the current file. This way, you as developer c…
I'm getting old, lol.
1 Like