C:\globals not accesible by the current user

[lobneroO]

I am trying to get a C++ qt cmake project to work with automaton, but I keep getting C:\globals is not accessible by the current user!

This happens already when executing one of the tasks, without using any variables at all. Current tasks.json:

// tasks
{
    version: "1.0.0",

    tasks: [
        {
            name: "Configure",
            cwd: "C:/Users/lobner/Dev/proof-of-concept/qt_glfw_interop",
            type: "shell",
            command: "cmake -G Ninja -S . -B ./build",
        },
        {
            name: "Build Debug",
            cwd: "C:/Users/lobner/Dev/proof-of-concept/qt_glfw_interop",
            type: "shell",
            command: "cmake --build ./build",
            depends: ["Configure"],
            default: true,
        },
    ]
}

I have rename launch.json and variables.json to make sure the error does not come from some read there, so I assume automaton just looks into my tasks.json right now.

OS: Windows 11 Neovim v0.10.0 LuaJIT 2.1.1713484068 Automaton v1.4.1

[Dax89]

Do you know where does neovim stores plugins on windows?

Automaton is trying to find this folder: https://github.com/Dax89/automaton.nvim/tree/master/lua/automaton/globals but it looks like this function is failing.

[lobneroO]

For me this is in C:\Users\myuser\AppData\Local\nvim-data\lazy\automaton.nvim\lua\automaton\. I assume that this would be a different path for different package managers. Pretty sure the nvim-data folder can be fetched with vim.fn.stdpath("data") though, that's how I bootstrap lazy on both Linux and Windows

[Dax89]

Can you change this function of your local copy of automaton as:

function Utils.get_plugin_root()
    local r = tostring(require("plenary.path"):new(debug.getinfo(1).source:sub(2)):parent())
    vim.print(r)
    return r
end

Just to make sure that the issue comes from that function :)

[lobneroO]

I do not see a difference in the output with the adjusted function

[lobneroO]

Not sure if this helps, but here is a screen recording

https://github.com/Dax89/automaton.nvim/assets/17877050/d6f687b4-ad64-4c52-9e80-e2564867f150

[Dax89]

Ok, so get_plugin_root should be fine.

I have looked the video, so it happens when you try to execute a custom task/launch command? I will check that part tomorrow and see if I find some suspect line of code!

[lobneroO]

I think it even happens before trying to execute the command. You can see the error is printed upon opening the tasks floating window, so before actually starting the task

[lobneroO]

Looked a bit deeper into this. stacktrace is:

...ocal/nvim-data/lazy/plenary.nvim/lua/plenary/scandir.lua:165: in function 'scan_dir' ...nvim-data/lazy/automaton.nvim/lua/automaton/variable.lua:92: in function 'get_globals' ...vim-data/lazy/automaton.nvim/lua/automaton/workspace.lua:93: in function 'get_current_variables' ...vim-data/lazy/automaton.nvim/lua/automaton/workspace.lua:145: in function 'get_tasks' ...vim-data/lazy/automaton.nvim/lua/automaton/workspace.lua:223: in function 'show_tasks' ...cal/nvim-data/lazy/automaton.nvim/lua/automaton/init.lua:472: in function <...cal/nvim-data/lazy/automaton.nvim/lua/automaton/init.lua:429>

init.lua 472 is the ws:show_tasks() call, which hangs ons self:get_tasks(). This calls self:get_current_variables() and the problem then arises in globals = Variable.get_globals(). Here it is not the Utils.get_plugin_root(), but the Scan.scan_dir that seems to be problematic.

I have gone to print the get_plugin_root() path, which is returned as C:\. This seems to be wrong, and C:\globals does not exist (so use can't have access).

Printing the root path on WSL returns ~/.local/share/nvim/lazy/automaton.nvim/lua/automaton, so this looks correct and tells me that on Windows it should be C:\Users\MYUSER\AppData\Local\nvim-data\lazy\automaton.nvim\lua\automaton.

I went to look at get_plugin_root(), specifically the debug.getinfo(1).source:sub(2) call returns C:/Users/MYUSER/AppData/Local/nvim-data/lazy/automaton.nvim/lua/automaton/utils.lua, so that looks correct.

The plenary :new(...) also works fine. However, calling :parent() reduces the path to C:\, so it goes to the root rather than just the parent folder.

Looking at the plenary path.lua, it internally returns either the internal _get_parent function's return value as a path, or path.root(self:absolute()). So this seems to be the culprit. In the _get_parent it looks for a path separator. On Plenary on Windows, that is "\", but in your paths fetched in get_plugin_root(), they are the Unix style "/" (this is in both Powershell and Git-Bash).

Long story short, it can be fixed with:

function Utils.get_plugin_root()
    local this_path = tostring(require("plenary.path"):new(debug.getinfo(1).source:sub(2))) --:parent())

    if package.config:sub(1, 1) == '\\' then
        -- we are on windows. debug.getinfo(1).source incorrectly returns 
        -- a path using '/' as path separator. plenary's :parent() can't
        -- handle these, therefore replace them
        this_path = this_path:gsub("/", "\\")
    end

    return require("plenary.path"):new(this_path):parent()
end

[Dax89]

Oh, wow that was tricky!

If you want, you can send a pull request so you get credits for this fix, otherwise I push it as commit and I mention you.

[lobneroO]

Sure, here is the pullrequest