Import doesn't resolve a file `module` argument relative to the modules folder

[rgchris]

When importing a module using a file argument (or a block of files), IMPORT/LOAD-MODULE does not resolve modules relative to the modules folder.

>> import %test-mod.reb

** access error: cannot open: %test-mod.reb reason: "not found or not valid"

Where $HOME/.rebol/modules/test-mod.reb contains:

Rebol [
    Title: "Test Module"
    Date: 25-Aug-2025
    Version: 1.0.0
    File: %test-mod.reb

    Type: module
    Name: rgchris.test
    Exports: [
        test-print
    ]
]

test-print: func [] [
    print "Test from Module"
]

I recognise this might not be a bug—rather leaving open the possibility of importing files relative to the current folder. In which case it precludes the possibility of loading modules in a subfolder of the modules folder when used as a word, e.g. import rgchris/test-mod vs. import %rgchris/test-mod.reb. My sense is that if a file is not found relative to the current folder, it should be checked against the modules folder.

[Oldes]

Yes.. by design it is now used to load module from exact location. It make sense that it coul also look inside the modules directory.

All this module juggling is quite a mine field. Any ideas how to improve it are welcone.

[rgchris]

I don't know how much scope there is for simplification. My feeling is that having the start paths organised is a key part of it.

As I recall, there was quite a diverse set of requirements placed on modules—with hindsight, it might be possible to weed some of these out. Some places I go back to to try and decipher how current modules evolved:

• Rebol 3 Wiki
• Carl's Notes
• BrianH's Notes

There's a lot of stuff in here that was just left unfinished—both in design and implementation. Too much really.

---

One option might be to put together a little scheme wrapped around the DATA folder. I think it'd be better than using WORD! to access modules, something like reb:xml (auto-resolves) or r3:someuser:thing or reb:rgchris:my-module@1.0.0 which could contain some logic for lazy downloading core modules the same way that words do now. Taking this approach would move a lot of the complexity out of LOAD/IMPORT and move it to the scheme without any real loss in clarity.

[acook]

In some languages relative path searches are allowed by prefixing the path with a ./ or by using a different import function.

For example, Ruby, I believe used to do the former, but for security reasons moved to the latter: splitting it into require and require_relative.

[rgchris]

The more I think about it, the more I believe that a scheme is the right idea. It separates concerns quite neatly—it streamlines the LOAD/IMPORT functions and moves all version resolution to the scheme. Not only that, there can be different implementations of the scheme that, say, pulls modules from a database instead of the filesystem (useful, perhaps, for a Server build).

Rebol [
    Title: "My Script"
    Needs: [
        r3:xml
        r3:me:my-functions
    ]
]

... xml stuff ...

Just get rid of words in IMPORT altogether

[rgchris]

Here's a working version of a scheme that would fit this purpose:

prot-modules.reb

Much of the functionality of IMPORT/LOAD-MODULE could be moved into this scheme.

Usage:

Rebol [
    Title: "My Script"
    Needs: [
        r3:xml
        ; works as the word 'xml works currently

        r3:rgchris:deflate
        ; resolves to ~/.rebol/modules/rgchris/deflate.reb

        r3:rgchris:deflate@0.1
        r3:rgchris:deflate@0.1.x
        ; (eventually) ensures a version matching 0.1.x

        r3:rgchris:deflate@1+
        ; (eventually) ensures a version matching 1.0.0 and up

        r3:rgchris:deflate?delay
        ; allows for extensible options (could use web conventions, or not

        r3:rgchris:image.png
        ; allows for alternate filetypes (broken)
    ]
]

Some design choices:

• Uses : instead of / so as to imply a conceptual entity rather than a literal file path—other implementations of this scheme might use non-filesystem ways of resolving these URLs
• Version and Options are currently placeholders, this leaves open the option of backwards/forward-compatibility
• I have some mixed feelings about whether user modules should be ~/.rebol/modules/user/ or ~/.rebol/user/modules/. The latter would allow simple Git cloning of someone's Rebol 3 Scripts repository into the .rebol folder, while the former might mean symlinking a folder into modules. The former doesn't impose any naming schemes on a user's folder though...

[rgchris]

This branch enables the initial module management scheme. I'd recommend it's incorporation even at this stage as it works as intended and does not currently affect other values in the IMPORT/NEEDS dialect. Over time, much of the complexity of module version control can be devolved to this scheme.

[Oldes]

Thanks... I must find some time to concentrate on it.

[Oldes]

It definitely should be ~/.rebol/modules/user/.

[Oldes]

Question is, how should be these user modules stored in runtime? Using the url (e.g. rgchris:deflate) as a key in system/modules?

[rgchris]

Question is, how should be these user modules stored in runtime? Using the url (e.g. rgchris:deflate) as a key in system/modules?

For now, there should be no change from current behaviour when loading user modules from any other URL—if they have a NAME header (WORD!), that's how they get stored in SYSTEM/MODULES. (* see below)

I think that could change if modules are referred to either by file or URL. URLs—particularly ones that contain version numbers—are fairly definitive. There's no ambiguity if a script uses r3:someone:stuff and includes a module that uses r3:someone:stuff@2.x (**)—the modules are loaded separately (even if they resolve to the same code) but never loaded twice (say, if another module asks for r3:someone:stuff@2.x). There may be a conflict with matching EXPORT values, but that's a separate issue (as you say, modules still have some wrinkles). It would at least take the burden off Rebol in managing versions.

The beauty of this scheme is that it doesn't actually change any of the current behaviour (nothing will break as a result of adding it)—so long as the basic functionality works (r3:xml = 'xml, r3:someone:thing = user module), it'll give you a flexible framework for changing the whole module system over time.

---

*As I understand, if they don't have a NAME header, there's no way to track them, per BrianH:

Unnamed Modules

As explained above, if your module doesn't have a name then it pretty much has to be treated as private. More than private though, since you can't tell if it's loaded, you can't upgrade it or even keep from reloading it. But what if that's what you want?

In some cases, you really want your code run for effect. In these cases having your code rerun every time is what you want to do. Maybe it's a script that you're running with do but structuring as a module to avoid leaking words. Maybe you're making a mixin, some utility functions that have some local state that needs initializing. It could be just about anything.

I frequently make my %rebol.r file an unnamed module because I want to have more control over what it exports and how. Plus, since it's done for effect and doesn't need to be reloaded or upgraded there's no point in giving it a name.

---

**Also, need to drop the @2.* form, @2.x works just fine.