[RFC] ~/.wren directory

[clsource]

Having a .wren directory in home (%AppData% in Windows) can be useful for configuration files and custom code extensions (both in wren files and if implemented in the possible ffi plugins).

Inside Wren files one can use this format

import "~/mywrencode" for WrenCode
import "~/utils/env" for Env

That could be translated to

import "/usr/home/myuser/.wren/mywrencode" for WrenCode
import "/usr/home/myuser/.wren/utils/env" for Env

A simple tree structure can be the following

.wren/
├── .wrenconfig.wren
├── mywrencode.wren
└── utils
    ├── env.dll
    ├── env.dylib
    ├── env.so
    └── env.wren

Related

• Proposal: User-defined native modules #52
• [RFC] Persist the Repl history to disk between launches #70

[joshgoebel]

I'd suggest .wren/libs/mywrencode.wren rather than having a ton of libraries at the top-level. I suppose your way allows for this, but doesn't encourage it. I think we should encourage it. Imports could be relative to lib allowing for simply:

// loads ~/.wren/lib/mywrencode.wren
import "mywrencode" for MyStuff

I'm not sure we need to redefine what ~ means (the users home directory).

[joshgoebel]

We currently have 3 path types:

  // An absolute path, starting with "/" on POSIX systems, a drive letter on
  // Windows, etc.
  PATH_TYPE_ABSOLUTE,
  
  // An explicitly relative path, starting with "./" or "../".
  PATH_TYPE_RELATIVE,
  
  // A path that has no leading prefix, like "foo/bar".
  PATH_TYPE_SIMPLE,

I propose:

• Add PATH_TYPE_HOME that resolves via ~/.wren/lib or the WREN_HOME environment variable - and that is the type when the path name has no leading prefix.
• Change PATH_TYPE_SIMPLE to PATH_TYPE_BUILT_IN and add a prefix, perhaps #. Or perhaps no prefix and both library and built-ins remain "simple" with the caveat that you cannot override library names... ie os is simply a "reserved" namespace and it's impossible to have an external library named os...

import "#os" for System, Time

The second suggestion is probably simpler (no specific chars) without getting into <> vs "" like with C. :-)

[joshgoebel]

Also perhaps a wrenrc that's always loaded into the CLI?

[clsource]

I like the idea. Redefining home seems weird to do.

For the lib directory I would not force it since you will loose access to the config files.

One solution would be to first check if the file exists in home. If not then check home/lib before aborting import

[joshgoebel]

For the lib directory I would not force it since you will loose access to the config files.

How so? They can live in ~/.wren, but the libraries still live in ~/.wren/libs... I don't see any issue there? Or do you mean the config files are normal wren files that you would import BUT they are not libraries... what is the use case for that?

[clsource]

I don't have an specific use case.
But I think some library can have a specific config file that could be read from there.

And since Wren does not have json support is easier to create config files that contains Wren objects.

[joshgoebel]

@clsource Are you aware of the existing wren_modules behavior? I wonder how it integrates with this proposal?

[clsource]

I didn´t know much about them either. But since they are available. Can be a directory called wren_modules inside the wren directory. So in the root wren directory you could store non module files and in wren_modules, you can use it for storing wren modules 👍

[joshgoebel]

Ok... so wren_modules lookup already has some behavior (given to us from the CLI). So if we add the idea of ~/.wren/wren_modules (I'd prefer just .wren/modules as a special case)

Then (assuming there were no other wren_modules):

// wren_modules is resolved to ~/.wren/modules/
import "booger"         // => ~/.wren/modules/booger/booger.wren  (existing CLI behavior)
import "booger/sugar"   // => ~/.wren/modules/booger/sugar.wren   (existing CLI behavior)

So the question is what happens if there is already another wren_modules? Right now all directories are scanned from the scripts own directory (all the way to root) looking for wren_modules.

• Would that directory walking simply not happen if ~/.wren/modules were found?
• Or if an up-dir wren_modules is found, do we ignore ~/.wren/modules if it exists?
• Or do we find and use BOTH to resolve modules?
  • If so, what order would they be searched?
• Then it's again an open question again how does one load a NON-module from .wren...

The whole idea of non-modules kind of bugs me still... I feel like if you just want to get a single file why not just load it directly (no magic):

import "~/.wren/config"
// or
import "%(WREN_HOME)/config"

And the CLI would inject WREN_HOME into the scripts scope...

Thoughts?

[joshgoebel]

FYI: I do think you need both... since you might have a large project with it's own wren_modules (just like node_modules) but then it might still make sense to have "globally" installed modules... so perhaps both are found but ~/.wren/modules is checked last (if the module can't be resolved with the up-dir wren_modules)?

[clsource]

I am closing this since #114 is a better scope to this :)