Inability to import resources

[amano-kenji]

• Project-local resources mean directories and resource files(jpg, txt, ...) in the current jpm project.
• Third-party resources mean directories and resource files(jpg, txt, ...) in other jpm projects that are already installed.

This issue exists whether JANET_PATH contains one path or multiple paths. If JANET_PATH is only one path, then one can use syspath which at least works after installation but still fails before installation.

There are several ways to import resources.

• Import the paths to resources
• Import the contents of resources. In case of directory, directory files can be available as a struct that maps file names to contents.

Jpm library (declare-source)

• Relative import: Project-local resources and third-party resources can be imported as paths or contents.
• Plain import: Project-local resources and third-party resources can be imported as paths or contents after installation
• Runtime resource search function can be written to work after installation

Jpm executable (declare-executable)

• Relative import: Project-local resources can currently be imported as contents only. Third-party resources can be imported as contents and paths.
• Plain import: Third-party resources can be imported as paths and contents. Project-local resources cannot currently be imported.
• Runtime resource search function can be written to work after installation

Current situation

• No built-in way to import resources or search runtime resources.
• People use syspath which doesn't work before installation and if JANET_PATH contains multiple paths.
• I don't know janet maintainer's plan to natively support resource import or runtime resource search, or his willingness to accept such native support from other people's pull requests.

[amano-kenji]

My thought experiments led to several ideas. Here, compile-time means the span of time during which a jpm executable is compiled.

• Importing the contents of compile-time resource files(jpg, txt, ...) with import
  • Relative import will be used to import project-local resource files. Plain import may be used to import third-party resource files, or import may omit native support for compile-time third-party resource files because third-party resource files can be handled with import-path described below.
  • Good for a few small files.
• Importing the paths to compile-time third-party resources with import-path.
  • This can be used to import paths to third-party resource directories and third-party resource files.
  • This can probably work for first-party resources during installation if declare-source is called before decalre-executable, but it won't work for first-party resources before installation.
  • Useful if there are many big resource files that can exist in a third-party resource directory.
• Runtime resource search function
  • Paths will be relative to JANET_PATH.

I don't know what janet maintainer wants or his vision of resource handling, but the first two ideas look good to me.

[sogaiu]

Sorry, I haven't really digested the above in detail, but I wanted to point out a work-around / hack that might cover a case or two.

This is not meant to discourage any efforts to provide a "proper" method, just an "in the meantime" kind of a thing (^^;

In at least one project, I used module/find to get the paths of some .janet files which were being used as data (not treating them as code)...

So, it seems to me that if one didn't mind choosing a filename extension of .janet or .jimage for one's resource files (even if the content doesn't match that of the file extension), module/find might be used to retrieve a path for such a file. Perhaps this makes certain resource file scenarios at least doable, if not exactly "nice".