Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

reworking relative requires #1934

Open
Jan200101 opened this issue Nov 9, 2024 · 0 comments
Open

reworking relative requires #1934

Jan200101 opened this issue Nov 9, 2024 · 0 comments

Comments

@Jan200101
Copy link
Contributor

Jan200101 commented Nov 9, 2024

Came up in Discord, I'm personally not too happy with the current resolve implementation that overwrites the function and has to store the state.

For this 3 choices were layed out:

  1. Keep the current system that just works™️, simple (as in you don't need to pass other variables), can workaround the init/not init by using . vs ..

  2. Add parameters to require that take the current modpath and actual path:

local modpath, path = ...
require("thing", modpath, path) -- also:
require("thing", ...)
  1. Add helper functions that allow the user to calculate the modpath:
local common = require "core.common"
require(common.relmod("thing", ...))

with me later proposing a 4th:

  1. searcher that walks the stack back and derives the relative modname by inspecting the stack
local searcher0 = package.searchers[2]
table.insert(package.searchers, 1, function(modname)
  if modname:sub(1,1) ~= "." then return nil end

  local _, parent = debug.getlocal(3, -1)
  local _, path = debug.getlocal(3, -2)

  if parent == nil or path == nil then return nil end

  -- Check if we imported a module or a file
  if path:match("init.lua$") == nil then
    parent = parent:match("(.-)%.[^%.]+$")
  end
  modname = parent .. modname

  return searcher0(modname)
end )

(incomplete implementation, but shows you roughly how it would work. Far more efficient when written in C)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant