Conversation
vhyrro
force-pushed
the
push-tsxzyvpzrorv
branch
from
b333780 to
4edb529
Compare
|
Some of this code is not really clean, I'll be honest. The next step will be to finish off the project functionality (with even more hacky code), write tests for everything and then start aggressively refactoring :) |
rocks-lib/src/build/mod.rs
Outdated
| let lua_version = LuaVersion::try_from(&rockspec)?; | ||
| // TODO(vhyrro): Create a unified way of accessing the Lua version with centralized error | ||
| // handling. | ||
| let lua_version = config.lua_version.clone().or(rockspec.lua_version()).ok_or_eyre("lua version not set! Please provide a version through `--lua-version <ver>`")?; |
There was a problem hiding this comment.
question: what if the rockspec's lua version is incompatible with the config's lua version?
Would it be better if the rockspec took precedence here?
There was a problem hiding this comment.
I think conflicts should result in an error. If a user explicitly requires Lua 5.1, but their project is in conflict, then allowing it could only cause problems down the line (think about executing in scripts, for example, where a user downloads a 5.1 package only to find out it has ended up in 5.3 instead). Supplying a Lua version is an explicit action, so we're doing the user a favour by letting them know about conflicts.
There was a problem hiding this comment.
right, I was thinking of how luarocks lets you specify the default lua version in a global config file.
There was a problem hiding this comment.
In the case of a global config then these shouldn't clash, you're right. I've been considering calling the future config value preferred_lua_version for this reason :)
|
Okay I think everything is done for this PR. |
2 participants
This is a draft implementation of project-local rock trees. If
rocksdetects it's in a project, it will always interact with the project-local rock tree first. Pass--no-projectto prevent these interactions.