Reusable third-party module support

[avivbeeri]

The goal of this issue is to discuss the implementation of something like NodeJS or Python modules, which can be developed and distributed for use across multiple projects with ease.

Any changes to the module-loading system should be backwards compatible with current projects, otherwise we will have to defer it to DOME 2.0.0

I think my own preference would be to extend the .egg/.tar loading system and use that file format for distributing modules.

As far as indicating that part of a module is being imported, I'd expect something like:

import "@domepunk" for PRNG

or, possibly allowing access to sub-files within a module using:

import "@domepunk/sub/path/to/Random" for PRNG

The hard bit is that DOME would need to keep track of which "module context" it was in, in order to resolve modules properly, as well as other rabbit-hole issues.

[clsource]

Dome Module Imports

For simplifying code reutilization and modularization,
this is a proposed way for DOME to handle dependencies.

modules.wren

This is a simple wren file that contains
each module path. Is inspired on https://github.com/WICG/import-maps

var Imports = {
    "domepunk": "modules/domepunk/dp.wren",
    "domepunk/": "modules/domepunk", // allow imports for files inside the domepunk/ dir
}

On startup DOME will load this file (if exists) and store the paths for reference later
when loading imports inside wren files.

The filename could be overrited using --importmap=<FILE> CLI flag.

tar files

Paths that end with tar will be considered as a tar file.
Using @ after the file extension it would mean a file inside the tar.

var Imports = {
    "domepunk": "modules/domepunk.tar",
    "domepunk/math": "modules/domepunk.tar@science/math"
}

importing

• Using @ at the start of the import will use the importmap path first.

• Without using @ it would follow the traditional way of importing and use the importmap last for resolve it.

• If the paths begins with / ("/domepunk") it would consider the base path of the dome executable.

• If the path does not begins with / ("domepunk") it would consider the base path of the main.wren file.

• If the path begins with ./ ("./domepunk") it would consider the base path of the current file begin executed.

// Will use the math module path defined in modules.wren
import "@math" for Math

// Will use the same path for the _dome_ executable as the base path. if not found will look into the modules.wren path
import "/math" for Math

// Will use the _file_ path as base path. Then it will look for the _main.wren_ base path. Then it will look for _modules.wren_ path. Finally it will look for the _dome_ executable base path.
import "./math" for Math

// First it will look for the internal modules. Then it will use the _main.wren_ base path. Then it will look for the _file_ base path. if not found will look into the modules.wren path. Finally it will use the _dome_ executable base path.
import "hello" for Hello

default name

Modules can define a default main.wren file that will be loaded by default if no file is specified for the path.

[clsource]

Based on the proof on concept. This is the proposed algorithm for resolving imports.

• First it resolves the import using the traditional way of the path based on main.wren.

• If the file is not found then it will look inside a modules dir.

• If the file is not found in modules directory then it will look for a path inside dome.ini.

• finally it will trigger import error for file not found.

• Example:

import "domepunk" for Dp

• This first will look for a file named domepunk.wren in the base path of main.wren.

• Then it will look inside basepath/modules/domepunk.wren.

• Then it will look inside basepath/modules/domepunk/domepunk.wren.

• Then it will search for a key named domepunk inside dome.ini

• If a key is found then it will look for a file inside {dome.ini.path}/domepunk.wren

• Example:

import "domepunk/utils/clock" for Clock

• This first will look for a file named clock.wren in the base path/domepunk/utils of main.wren.

• Then it will look inside basepath/modules/domepunk/utils/clock.wren.

• Then it will search for a key named domepunk inside dome.ini

• If a key is found then it will look for a file inside {dome.ini.path}/utils/clock.wren

• Example:

import "../domepunk/utils/clock" for Clock

• This first will look for a file named ../clock.wren in the base path/../domepunk/utils of main.wren.

• Special paths like ./ or ../ are omited in the modules search after the traditional way.

• Then it will look inside basepath/modules/domepunk/utils/clock.wren.

• Then it will search for a key named domepunk inside dome.ini

• If a key is found then it will look for a file inside {dome.ini.path}/utils/clock.wren

• Example dome.ini

[imports]
domepunk = examples/

[Kasparsu]

I think this is a great idea. I think also a package manager would be in effect that could deal with modules as well as plugins both. Doesn't need to be anything fancy maybe just a repo with list of github links and a wrapper on git clone or wget. Could have a dome.json and dome.lock.json files emulating bit of node.js. Or perhaps take a note from pnpms book and download dependancies to a central location and then just symlink them. Saves on diskspace if using same stuff for many projects