> If I follow you correctly, you removed this because the luarocks wrapper loads luarocks.loader and essentially does this job, right?

Well, if you were able to `require` `luarocks.cfg` you already have your `package.path` set up so that you can load the other luarocks modules. So this modification of the `package.path` is only necessary if you later add another rocks tree to the repository *and* you want luarocks to load a module from there. And in that case, yes, it should be the job of `luarocks.loader` to add those paths (I think it doesn't do that yet) ...

But I think we need to decide, which module may mess with the `package.path`. At the moment, we modify the paths in the Makefile, in `luarocks.cfg`, and in the wrapper scripts. I had to remove it from the Makefile and `luarocks.cfg` to fix this issue. The wrapper scripts are enough *unless* you want to load module from rocks trees that were added *after* the wrapper script was created. Do we want/need that? If yes, the wrapper script should only add the necessary path to find the `luarocks.loader` module, and let `luarocks.loader` add all current rocks trees to the path. That would also fit well with the current installation paths on Windows, where the luarocks modules are installed outside of the rocks trees.

> If we remove this I think I'll have to make build_bins add a require("luarocks.loader") for the non-bootstrap mode.

The build_bins target adds the first rocks tree to the path, which is enough to find the luarocks modules. If we need modules from other rocks trees, then yes, we need to require `luarocks.loader` there too. But is there a reason to keep the non-bootstrap mode around on Unix?