Module System Design

Requirements

• Ability to load specified module of specified version
• Flexibility regarding where modules (each one, independently) are placed in the file system
• Support to run multiple NGS versions on the same machine (support loading per-NGS-version bootstrap.ngs, stdlib.ngs etc)

Design

• For simplicity, for now a file is a module
• There will be explicit distinction between relative file and files looked up in the search path
• Current directory will not automatically be part of the search path

Search path

As in many other languages an environment variable (with some default) will be used to control the search path of the modules. That would be the NGSPATH environment variable.

Default search path:

• $HOME/.ngs/lib
• /usr/local/etc/ngs
• /usr/local/lib/ngs
• /etc/ngs
• /usr/lib/ngs

At start, REQUIRE_PATH global variable will be set from the NGSPATH environment variable. REQUIRE_PATH (array of strings) will be used by the require() method (or by ngs.c during early bootstrap).

Directory layout (WIP)

• SEARCH_PATH_ITEM/MARKER_FILE (marker file to make sure it's really packages root, not sure at all)
• SEARCH_PATH_ITEM/PACKAGE_NAME/PACKAGE_VERSION/SOME_PACKAGE_FILE (not sure at all)

There are no "index" files, whoever requires a package should know the name of the file in the package; one can not require a package, only specific file. (Sounds like require() will be verbose, not good).

Open issues

• When specifying modules version - is it from code or from some definition file?
  • From code - allows one-file-module.
  • From definition file - allows flexible version change without touching the code.

Take a look at

For design requirements and ideas, we should look into (alphabetical order):

• Apache Maven
• Bundler
• Cargo
• CPAN
• epm
• pip
• rbenv
• rvm
• npm - I like that everything is contained (does not need to be installed system-wide) and works as long as you run the correct node binary.
• virtualenv - Don't take the bad part of hard coding absolute paths