Re: About the Lua paths on Windows

["Andre Carregal" <carregal@...>]

On 5/14/07, Stefan Sandberg <keffo.sandberg@gmail.com> wrote:
> I fail to see the ultimate goal here, I treat the "default"
> package-paths as an example of how to use it, not something that
> dictates how and where I put my files.
> For example, I still need two diff. builds for 32 and 64bit of luasocket.

True, but if we could at least make live easier for those on the
default path it would be a nice addition. And, as Jerome suggested, we
could continue to support "/" for both C and Lua modules, while using
"/lib" and "/lua" for nicer directories if wanted.

This would make life a lot easier for those who, like Kepler, have to
call an interpreter in order to run some application (say Xavante)
that is in fact a module.

> Something that does bug me is how annoying those paths are to create in
> the first place, or to debug, so if anything should be changed, I would prefer
> a very simplified helper function that makes it easy to change those
> paths.. (which is usually the first thing I write anyway)
> There are always people popping in to #lua asking why this'n'that isn't
> loaded, and how the paths work, so I think it's justified.
>
> Actually, while we're at it, wouldn't this fit nicely in some sort of
> package-loader utility function?
> Each loader is preset with a path (like what's suggested here), and also
> has a function to add/remove a path from itself..?
>
> Me rambling, ignore if it's weird, I just don't like writing those paths :)

Adding some "pre" and "post" path handling is not weird per se, but
that would be an issue for Lua 5.2. I'm trying to check if the change
of the default paths for Windows could be made for 5.1.3.

If so, we could have a new release of LuaBinaries with those paths and
then both Kepler and LuaRocks (if not others) would benefit from the
changes right now.

For example, one benefit of such a small change could be explaining to
new users (on Windows at least) that they should put the modules on
the /lib or /lua directory, not "on your package.cpath or
package.path". As you mentioned, this path thing makes sense after you
get the whole picture but I think it is a burden for a first contact
with the language.

André