search

lunarmodules / busted

Elegant Lua unit testing.
https://lunarmodules.github.io/busted/
MIT License
1.38k stars 184 forks source link

build: add luarocks.lock #709

Closed chenrui333 closed 1 year ago

chenrui333 commented 1 year ago

Lockfile is a way to ensure the repeatable build, thus adding the lockfile and update make builds to use --pin

also relates to https://github.com/Homebrew/homebrew-core/pull/117679

Tieske commented 1 year ago

not sure about this. Not familiar with the lock files. If versions go out of sync, shouldn't the depedencies in the rockspec file be updated?

chenrui333 commented 1 year ago

Not familiar with the lock files.

lockfile is just a way to ensure repeatable builds

If versions go out of sync, shouldn't the depedencies in the rockspec file be updated?

spec is spec (specifying version constraint), lockfile is lockfile (specifying exact version that is being used)

chenrui333 commented 1 year ago

I dont think it works as I anticipated, closing this PR for now, we can revisit it later.

chenrui333 commented 1 year ago

Thanks @alerque!

Tieske commented 1 year ago

Many/most projects I work on are explicitly designed and tested to run on multiple versions of Lua.

This is something new to me, but I already saw it yesterday. Also when did check the lua release cycle on the site, I found almost all the old versions are kind of unsupported (the last release was long time ago), I am bit confused about lua's release lifecycle.

The main reason for this is that Lua is an embedded language. (not as in hardware, but as embedding it in other applications to make them scriptable). This typically means that those host applications have their own ecosystem with Lua code. And hence upgrading the Lua version does not make sense as it is extremely intrusive. So unless you really need a feature (UTF-8 for example), you stick to the original version you started with.

It's the embedded nature that makes this different from other languages, where the tendency is to stay current.