system.engiePrefix point to a wrong directory

[Gozala]

As far as I can see while playing with tusk all the non-included engines are installed to the packages directory (not sure if it's a right behavior though), while enginePrefix points to the non existing path narwhal.js:58. This way you can obtain circular module require's between default/system and logger (That's what I had with xulrunner engine), unless first element in the system.prefixes points to the engines folder. But even in this case it seems to be consequence rather then expected behavior. I also found that it causes a bug on xulrunner engine cause in order to bootstrap worker I need a path to the engines bootstarp, but fs(system.enginePrefix).join("bootstrap.js") doesn't exists as it points to the directory engines/xulrunner/bootstarp.js while it suppose to point to packages/narwhal-xulrunner/bootstarp.js.

There is also different thing. Structure of the xulrunner-engines extension looks like:

bootsrap.js
packages.json
lib
    ....
narwhal
    engines
    packages
    ...

Take in mind that xulrunner engine is nor in narwhal/engines nor in narwhal/packages there for it can be constructed by narwhal.js. I would suggest to assign value system.enginePrefix in the bootstrap.js of the engine instead this was problem will be solved. I don't want to create patch as I'm not sure weather or not I'm missing something if not let me know so I'll make a patch. BTW all the engines would have to apply these on their side as well.

[Gozala]

this issue also related to this one

Fix can be as easy as

system.enginePrefix = system.enginePrefix || system.prefix + '/engines/' + system.engines[0];

[tlrobinson]

Engines can also be installed in the packages directory.

The engine should know it's own location and should provide it to narwhal.js somehow.

[kriskowal]

Also, system.prefixes[0] is expected to be the sea root, for the purpose of package discovery and tusk package installation. Threading system.enginePrefix through the bootstrap process is definitely the way to go.

[kriskowal]

This problem appears to require further consideration. Adding the engine prefix to prefixes might not be the right solution, rather sorting out the strange dependencies system and logger, and using enginePrefix in narwhal.js directly. system.prefixes is used by tusk and lib/packages.js as the resolution order for package discovery and new packages are installed in the "root" which is system.prefixes[0].

First, Tom, can we remove the .fs and .logger attributes of system? Would it be acceptable to mandate the requiring of those modules instead of using the system object to carry them?

Iraliki, can you test this problem on the refactor branch?

I'll put some thought to how to refactor narwhal.js and try to understand the problem for XULRunner more thoroughly.

[Gozala]

Well with refactor branch and NARWHAL_ENGINE_HOME removed from system.prefixes it looks like narwhal expects engine to be in a wrong directory on failure it defaults to default engine which still tries to require module from the engine and basically enters cyclic require cycle. Error stack looks like this:

("/Users/gozala/Projects/narwhal/engines/xulrunner/lib/file-engine")@/Users/gozala/Projects/narwhal/engines/default/lib/file-engine.js:56
......................................... (same line many times)
("/Users/gozala/Projects/narwhal/engines/xulrunner/lib/file-engine")@/Users/gozala/Projects/narwhal/engines/default/lib/file-engine.js:56
("file-engine")@/Users/gozala/Projects/narwhal/lib/loader/multi.js:32
("file-engine")@/Users/gozala/Projects/narwhal/lib/loader/multi.js:50
("file-engine","",true)@/Users/gozala/Projects/narwhal/lib/sandbox.js:52
("file-engine")@/Users/gozala/Projects/narwhal/lib/sandbox.js:184
([object Object])@/Users/gozala/Projects/narwhal/narwhal.js:122
([object Sandbox],(function () {return eval(arguments[0]);}))@/Users/gozala/Projects/narwhal-xulrunner/bootstrap.js:110
@/Users/gozala/Projects/narwhal-xulrunner/bootstrap.js:113

The problem with xulrunner engine is that engine lib is not under $narwhal/engines/xulrunner/lib/ actually that's a case with all the non narwhal included engines as the live under $narwhal/packages/$engine/.

Besides narwhal ff extension s packed in a way that engine lib is nor under $narwhal/engines/ nor under $narwhal/packages/ it actually lives on the same level as the $narwhal itself. I do believe that right solution will be a tweak to packages module so that it will look at system.enginePrefix in order to find where is the active engines lib is located.