luarocks pack ./foobar.rockspec creates unusable src rock about luarocks HOT 2 CLOSED

Thanks for the detailed report!

"luarocks pack" on a rockspec file creates a zip with the downloaded URL and the rockspec only. So, you're right, I think the right behavior in that case would be to fail when trying to pack once the source.url entry is found to be invalid.

I can't make "luarocks pack" work on the overall contents of the current directory (like "luarocks make") because the rockspec doesn't have enough information about which files should and should not be added (an example of this situation would be build.type="command").

So, I think the solution will be to make it fail on your "luarocks pack foobar-scm-1.rockspec" and just use make + pack for a situation like this. Does that sound sensible?

(I'm not entirely comfortable with using invalid source.url entries, but the use case looks reasonable -- in fact, this may be seen as an argument for making source.url optional in the rockspec format.)

from luarocks.

No problem if LR would fail in this case. Much better than current confusing behaviour anyway.

As for invalid (or missing) source.url, it is inevitable — for the case when rocks are to be created from unsupported source (like /was/ git+ssh or mercurial). So, it would be good if LR would support it explicitly.

I'm not sure if it is good idea to make source.url optional, maybe it would be more readable to force users to set it to false?

from luarocks.