DifferentialOrange
commented
1 year ago Using symlinks in the rock binary doesn't seems to be the best approach: even though you can copy a soft symlink to rocks/module/version/lua, luarocks seems to resolve it on files deploy:
tree.
├── dir1
│ └── file1
├── file2
├── link1 -> dir1
├── link2 -> file2
└── link3 -> notexist
2 directories, 4 filestarantoolTarantool 2.10.4-0-g816000e10
type 'help' for interactive help
tarantool> cfg = require("luarocks.core.cfg")
---
...
tarantool> fs = require("luarocks.fs")
---
...
tarantool> cfg.init()
---
- true
...
tarantool> fs.init()
---
...
tarantool> fs.is_file('link1')
---
- false
...
tarantool> fs.is_file('link2')
---
- true
...
tarantool> fs.is_file('link3')
---
- false
...
tarantool> fs.is_file('link1/file1')
---
- true
...
The ability to override built-in modules was introduced with [1]. To use it, you must install the package files using the override.package path for each file included.
Using soft links inside the rock seems like a bad idea -- luarocks try to resolve them on files deploy and fails to do so. The only stable approach is seems to be to duplicate the files to the override folder.
builtin rockspec doesn't allow to specify a single file twice, so we need to store the soft link in the repo to workaround it. To build override package with builtin rockspec, we'll also need to manually maintain two lists of package files.
cmake approach allows to automatize it. On the other hand, to work with cmake-built rock, you'll need to
makethe rock while working locally. Sincemake .rocksis a dependency ofmake test, it shouldn't be a big issue.After [2], metrics will be embedded to core Tarantool. The ability to override them with installed rock will make it possible to use old Tarantool with new metrics. cartridge role, which was embedded to tarantool/cartridge in [3], is also would be override.
Closes tarantool/tarantool#7727