Something like `import-path` for getting paths to jpm resource files.

[amano-kenji]

A few days ago, JANET_PATH started supporting a list of paths which are used by nix and guix.

This doesn't break existing users and is sufficient for janet modules, but janet hasn't yet been designed to find jpm resource files.

Because janet doesn't natively support finding jpm resource files, some janet libraries just use syspath. syspath won't work on purely functional package managers.

import-path will search JANET_PATH, but it also has to account for the current jpm project that hasn't yet been installed. --dest-dir and --modpath will affect import-path on the jpm project that's going to be installed.

jpm install will make import-path put the paths to jpm resource files in the compiled jpm executables. import-path and jpm install can eliminate the inefficiency of searching multiple paths in JANET_PATH.

[amano-kenji]

It turns out that import-path is not a hard requirement for nix and guix, but it will support purely functional package model. At least, guix supports languages that don't support multiple paths, but using those languages will break purely functional package model which allows me to install multiple versions of the same package.

Let's assume that B depends on A-1.1 and C depends on A-2.0. A-1.1 and A-2.0 are incompatible with each other.

Purely functional package model allows me to install B and C on the same system. If it is broken, I can't install B and C on the same system.

For now, I cannot install multiple versions of joy and any other jpm library that searches syspath for resource files.

For example, joy/cli/route.janet breaks purely functional package model. To support purely functional package model for everything, something like import-path.

[amano-kenji]

I haven't fully fleshed out requirements, yet. This issue will have to wait until I'm ready or someone else is ready.

[bakpakin]

Janet already has such mechanisms to support this pattern - the usual import macro. Purely functional package managers" are not special in how we need to require code from multiple directories.

[sogaiu]

On a side note:

This doesn't break existing users and is sufficient for janet modules

I don't think this is strictly true. We saw an example for one of subsetpark's projects that will break. It may not be hard to fix, but it is not unaffected.

It will also break one task in one of yumaikas' projects. Again, this may be easy to address, but it's still breakage.

These are some things we found in a short period of time and it's possible there weren't a lot more. But we don't know.

So it might not be a lot of breakage and it may be a tolerably small amount, but I don't think it is factually accurate to claim the changes don't break existing users.

For the record, I'm not overall opposed to the change (indeed I have wanted the ability myself -- there is a record of it in one of the Zulip topics), but I disagree about the view expressed in this issue and in this comment:

Supporting multiple paths in JANET_PATH doesn't break existing users

That doesn't match my understanding and I think it is misleading to summarize in this way.

[amano-kenji]

That doesn't match my understanding and I think it is misleading to summarize in this way.

I found the proof that it doesn't break existing users.

For now, if anyone uses multiple paths in JANET_PATH, janet can't import anything because janet didn't support multiple paths until recently. Nobody would keep using a broken janet installation.

I suggest it is misleading to suggest it breaks any existing user. Nobody on earth uses multiple paths in JANET_PATH for now. Not even bakpakin uses it. I don't use it for now.

The recent support for multiple paths in JANET_PATH doesn't change the behavior of janet if there is only one path in JANET_PATH.

[amano-kenji]

Purely functional package managers" are not special in how we need to require code from multiple directories.

This is not about janet code. This issue is about getting paths to non-code resource files like images, css files, and text files or embedding these paths in the compiled executable.

Since you haven't explicitly provided a standard way to deal with "resource" files like images and text files, people will naturally flock to syspath.

Have you considered one standard way to get paths to resource files? Haskell provides a standard function for getting paths to resource files. Raku provides a class that has a function for getting paths to resource files. Both haskell and raku have documentation for getting paths to resource files.

From my perspective, janet hasn't been explicitly designed to support resource files. syspath wasn't designed to support resource files, and people just used it for resource files later.

The fact that you can read https://janet-lang.org/docs/modules.html and someday come up with a creative way to add a one-off customized support for resource files to your own janet program doesn't count as native support. Most people won't even know this is a thing if there is no native support. If they ever figure anything out, it will be syspath which doesn't work when there are multiple paths.

I think it's time to define a clear stance toward resource files and multiple paths.

• You actually refuse a separate function for getting paths to resource files even if someone else implements it?
• Or, you are not personally interested but don't mind someone else implementing it?

[amano-kenji]

I also think janet code should not be intertwined with resource files in one function, import.

In simple made easy, rich hickey said complexity stems from two or more things intertwined. Intertwined things must be considered together.

What does (import ./dir) mean if import supports getting paths to resource files and directories?

• It means the janet module, ./dir/init.janet
• It means the path to ./dir.

Because janet module and path are intertwined in import, now import cannot differentiate between the two.

What if I want to read the content of a janet module to count the number of lines in it? import starts becoming more complex. Complecting two concepts in one function increases complexity.

Simplicity results when you separate two things apart. In this case, we should separate janet modules from paths. If you are going to support getting paths to files and directories in JANET_PATH, there should be a separate function for getting paths.

Simplicity sometimes requires more functions for separating things apart.

I'm not saying things like import-path should be implemented as soon as possible. No one has an immediate need for it, but things like simplicity and ease of understanding should be thought about.

@bakpakin Given your short responses, I understand you are probably not personally interested in it, but at least give it a read, and think about it.

[amano-kenji]

I condensed my thoughts on https://github.com/janet-lang/janet/discussions/1509