Re: libseed-list imports.searchPath

[Jonatan Liljedahl <lijon kymatica com>]

At the end of Seed.js, the code below will put the current script path 
at the start of imports.searchPath. But to get the current module's path 
there one will need to adjust the importer C code.

A much better approach would probably be to let 
seed_importer_get_search_path() return __script_path__ + searchPath, 
then it will work for the toplevel script as well as all modules.
Should I make a patch for this?

if(!imports.searchPath || (imports.searchPath.length == 0))
{
	imports.searchPath = [
		"/usr/share/gnome-js",
		"/usr/lib/seed",
		"/usr/share/seed",
		"/usr/local/lib/seed",
		"/usr/local/share/seed",
		"/usr/lib/seed",
		"/usr/share/seed"];

	if(Seed.argv.length > 1)
	{
		__script_path__ = GLib.path_get_dirname(Seed.argv[1]);
		
		try
		{
			if(!GLib.path_is_absolute(__script_path__))
			{
				__script_path__ = GLib.build_filenamev([GLib.get_current_dir(),
				                                      __script_path__]);
			}
		
			__script_path__ = imports.os.realpath(__script_path__);
		
			if(__script_path__ && __script_path__ != "")
				imports.searchPath = [__script_path__].concat(imports.searchPath);
		}
		catch(e)
		{
			print(imports.JSON.stringify(e));
		}
	}
	imports.searchPath.push(".");
}

Alan Knowles wrote:
> I think that would be a good idea, Once thing that I've found is that restructuring an application by renaming directories, or moving stuff around would be a little simpler if we allowed this.
>
> I have code in JSDOC/Instrospect - which should really be moved out of JSDOC subfolder, but since all the code inside that directory does imports.JSDOC.Instrospect..... (and the use case for that library is only about one file). the biggest effect of moving the directory is changing the code it'self rather than the use cases...
>
> Regards
> Alan
>
>  --- On 17/Jun/2010, Jonatan Liljedahl wrote: 
> > Tim Horton wrote:
> > > At least in $PATH, the current directory isn't put first for security
> > > reasons (if you're in a publicly writable directory, you don't want
> > > malicious users putting their own copy of -- for example -- 'ls' in that
> > > directory and having that unknowingly run by you when you're in that
> > > directory).
> > >
> > > I'm going to go with "that's by design". Or at least, by copying other
> > > people's design. It's not clear it matters as much here.
> > Ok, I can see the point of that.
> >
> > > There's no reason the directory of the currently running script couldn't be
> > > first, though. I think. I don't know :-)
> > That would be very good, I think!
> >
> > Also perhaps adding a modules path at the beginning while importing a 
> > module?
> >
> > say you have foo/Foo.js, foo/Bar.js and in Foo.js you do "b=imports.Bar" 
> > and you know that it will use the one in the same directory. In a 
> > security point of view, if we *don't* do this, then an evil user might 
> > alter imports.searchPath so it uses their evil version of Bar.js 
> > instead, etc..
> >
> > /Jonatan
> >
> > > On Wed, Jun 16, 2010 at 09:14, Jonatan Liljedahl <lijon kymatica com> wrote:
> > >
> > > > I see. But looking at imports.searchPath it has automatic added entries for
> > > > the home path of the running script and the current directory, but these are
> > > > added at the end. Shouldn't they be added to the beginning?
> > > >
> > > >
> > > > Tim Horton wrote:
> > > >
> > > > > No, we iterate over it in order (from first to last) as far as I remember,
> > > > > just like $PATH. If you want your stuff to get found first, prepend it to
> > > > > searchPath, again, just like $PATH.
> > > > >
> > > > > Could be wrong, it's been a while...
> > > > >
> > > > > On 2010.06.16, at 06:37, Jonatan Liljedahl wrote:
> > > > >
> > > > >  In what direction is imports.searchPath searched? I guess it should start
> > > > > > from the last one added? So that any custom paths are searched before system
> > > > > > ones..
> > > > > >
> > > > > > /Jonatan
> > > > > > _______________________________________________
> > > > > > libseed-list mailing list
> > > > > > libseed-list gnome org
> > > > > > http://mail.gnome.org/mailman/listinfo/libseed-list
> > > > _______________________________________________
> > > > libseed-list mailing list
> > > > libseed-list gnome org
> > > > http://mail.gnome.org/mailman/listinfo/libseed-list
> > _______________________________________________
> > libseed-list mailing list
> > libseed-list gnome org
> > http://mail.gnome.org/mailman/listinfo/libseed-list
>
> _______________________________________________
> libseed-list mailing list
> libseed-list gnome org
> http://mail.gnome.org/mailman/listinfo/libseed-list