Войти
ПрограммированиеФорумОбщее

Lua & Sol: additional include directories?

Страницы: 1 2 Следующая »
#0
20:07, 1 ноя. 2021

Не знаю, имеет ли значение использование Sol, указал на всякий случай.

Хочется иметь такую же возможность, как при компиляции C++ традиционными компиллерами - указывать несколько путей, по которым нужно искать инклюды (в нашем случае с Lua - модули, подгружаемые с require). Такое возможно? Чет ничего внятного нагуглировать не удалось.

Практическая цель такая: юзер пришет приложение на Lua, а модули, с которыми он хочет работать, лежат где-то отдельно, и у юзера к ним доступа нет (ну или просто они лежат отдельно для порядку, по аналогии со всякими бустами в /usr/include). При этом нужно сделать так, чтобы он мог подключать их без указывания абсолютного пути, типа так:

/home/user/projects/myapp.lua - юзерское приложение

local someService = require "services/some_service.lua"

someService.doSomething()

/home/admin/lua.libs/services/some_service.lua - библиотека, которую пилит админ

-- Какое-то содержимое

Соответственно, нужно чтобы юзерское приложение понимало, что require нужно искать в том числе в /home/admin/lua.libs. Это возможно?

Если прям ваще никак нельзя, то можно предложить какой-то воркэраунд, можно даже совсем шизанутый. Просто так сделать при запуске скрипта set current directory в /home/admin/lua.libs - не вариант, потому что нужно чтобы юзерские require видели и библиотечный код, и свой собственный (то есть чтобы юзер мог тоже локально писать свои модули и подключать их без абсолютных путей). То есть нужна возможность задавать несколько путей для поиска файлов по относительным путям/именам.


#1
(Правка: 21:51) 20:37, 1 ноя. 2021

DEN, а прописать этот путь в переменную окружения в той программе что читает скрипты не пробовал?
SET PATH="/path/to/dir"

local dir = os.getenv("PATH")
path = dir .. "/" .. "ts.txt"
В программе на паскале я делал так:
SetEnvironmentVariable(PChar( 'PATH'),PChar('/path/to/dir'));
C++
BOOL SetEnvironmentVariable(
  LPCTSTR lpName,
  LPCTSTR lpValue
);
#2
(Правка: 8:27) 8:27, 2 ноя. 2021

DEN
На крайняк можешь в require писать пути вот так:

local mod1 = require("%somePath/mod1.lua")
И перед тем, как отдавать скрипт луа, просто заменяешь %somePath на нужный путь.

Но вообще у луа должен быть свой механизм, надо читать доку по модулям.

#3
13:22, 2 ноя. 2021

Lua

require 'winapi'
winapi.setenv('PATH','/path/to/dir')

#4
23:00, 2 ноя. 2021

DEN
Луа ищет сишные либы по паттерну, указанному в переменной "package.cpath" (не переменная среды). Вы можете менять эту переменную под себя.

#5
(Правка: 23:23) 23:13, 2 ноя. 2021

kkolyan

package.cpath

Да, резонно!
Но, как я понял, ему надо не из LUA.
Допустим, художник пишет свой скрипт и не задумывается, где чего лежит.
Наверное это надо прописать в хостовой программе(С++) куда она должна заглядывать помимо своей папки.
#6
0:56, 3 ноя. 2021

flint2
Разумеется, в хостовом коде

#7
(Правка: 1:00) 1:00, 3 ноя. 2021

DEN
Насколько юзеру доверяешь? Если это прям юзер-юзер (а не член команды), то стоит запретить require, а загрузку либ делать в хостовом коде в глобальное пространство.

#8
1:43, 3 ноя. 2021
то стоит запретить require, а загрузку либ делать в хостовом коде в глобальное пространство.

Очень правильное замечание!
#9
(Правка: 4:39) 3:39, 3 ноя. 2021

либо можно require оставить (чтобы например иметь возможность знать какие предоставленные либы юзает тот или иной загруженный скрипт), но в виде враппера, который перед вызовом настоящего require выставляет правильные "cpath" и "path"

#10
15:49, 3 ноя. 2021

Всем спасибо за предложенные варианты. Пока что не уверен, что лучше подходит, но надеюсь скоро это понять. Я сюда еще вернусь :)

PS.

kkolyan
> Насколько юзеру доверяешь? Если это прям юзер-юзер (а не член команды), то стоит запретить require, а загрузку либ делать в хостовом коде в глобальное пространство.

А в чем подводные использовать require если я не доверяю юзеру? Типа он сделает что-то вроде

require "/etc/passwd"
и по тексту ошибок компиляции узнает коды доступа к главному компьютеру Зиона?

#11
16:12, 3 ноя. 2021

DEN
сам по себе require вроде относительно безопасен, но возможность с помощью него и фабрикации "package.cpath"/"package.path" шариться по файловой системе позволит злоумышленнику эксплуатировать возможные уязвимости.

#12
0:18, 26 ноя. 2021
Изображение


Так, а что если не заморачиваться с путями, и просто прогрузить все модули заранее перед выполнением скрипта?

Наверно тут нужно немного пяснить. Имеется некая "экосистема", в которой сторонний юзер будет писать свои скрипты, и эта экосистема из коробки предлагает свои вспомогательные модули. Юзерский код и модули экосистемы будут лежать в очень разных местах, и нужно, чтобы юзер мог одинаково удобно использовать как системные модули, так и свои собственные.

Тред начинался из предположений о том, что юзер должен писать require и для подтягивания своих модулей, и для подключения "системных". Но если системные модули написаны для одной и той же системы, то типа подразумевается, что там все грамотно организовано, в одном стиле, безо всяких клэшей имен, ну и вообще, заточено под задачи, которые будут возникать у этого юзера. Тогда почему бы просто не подгрузить все эти системные модули заранее через sol::state::script_file, чтобы они все сразу были доступны юзерскому скрипту безо всяких require? Можно считать, что дополнительным временем загрузки и памятью можно пренебречь. Какие тут еще будут недостатки? Ну типа юзер не сможет завести свои сущности с именами, совпадающими с системными модулями, это ясно. А еще?

#13
1:08, 26 ноя. 2021

DEN
при любом подходе тебе нужно будет защитить свои дефолтные модули от изменений со стороны клиентского модуля. То есть сам интерфейс юзер пусть ломает если хочет, но чтобы эта поломка не распространялась на другие скрипты. К примеру если юзер напишет:
math.min = function(a, b) print('debug min(' .. a .. ', ' .. b..')') ... end
то остальные скрипты не должны пострадать, либо запретить изменять вовсе. (читай как делать readonly)

#14
13:30, 26 ноя. 2021

Aroch
> при любом подходе тебе нужно будет защитить свои дефолтные модули от изменений со стороны клиентского модуля
> читай как делать readonly

Спасибо, почитаю. Но вопрос без-require-ных модулей остается открытым :)

Страницы: 1 2 Следующая »
ПрограммированиеФорумОбщее