Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reusable third-party module support #98

Open
avivbeeri opened this issue Oct 10, 2020 · 2 comments
Open

Reusable third-party module support #98

avivbeeri opened this issue Oct 10, 2020 · 2 comments
Labels
enhancement New feature or request on hold Consideration for future implementation

Comments

@avivbeeri
Copy link
Collaborator

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.

@avivbeeri avivbeeri added the enhancement New feature or request label Oct 10, 2020
@clsource
Copy link

clsource commented Oct 10, 2020

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
Copy link

clsource commented Oct 12, 2020

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/

@avivbeeri avivbeeri added the on hold Consideration for future implementation label May 3, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request on hold Consideration for future implementation
Projects
None yet
Development

No branches or pull requests

2 participants