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

when environment variable WEZTERM_CONFIG_FILE is specified, wezterm.config_dir is not part of modules search path #5579

Open
hgkamath opened this issue Jun 17, 2024 · 3 comments
Labels
bug Something isn't working

Comments

@hgkamath
Copy link

hgkamath commented Jun 17, 2024

What Operating System(s) are you seeing this problem on?

Windows

Which Wayland compositor or X11 Window manager(s) are you using?

NA (Windows)

WezTerm version

wezterm 20240203-110809-5046fc22

Did you try the latest nightly build to see if the issue is better (or worse!) than your current version?

No, and I'll explain why below
I guess the scoop installed version is sufficiently uptodate to demonstrate this bug.

Describe the bug

For the first time i was thinking of making a module as suggested in this link
https://www.reddit.com/r/wezterm/comments/1bbq6ro/i_implemented_a_theme_switcher/

The thing is, I install wezterm using scoop.
I create and maintain the configuration file in a .../scoopg/persist/ folder.
So I have an environment variable WEZTERM_CONFIG_FILE setup to point to the wezterm.lua file

I tried many ways of trying to require the module including giving the path as part of the module name but that does not work
local features= require 'features' ;

Perhaps the wezterm.config_dir should also be part of the path search ?

00:22:12.521  ERROR  mux::connui > Configuration Error: runtime error: [string "C:\vol\scoop_01\scoopg\persist\wezterm\wezter..."]:4: module 'features' not found:
        no field package.preload['features']
        no file 'C:\vol\scoop_01\scoopg\apps\wezterm\current\wezterm_modules/features.lua'
        no file 'C:\vol\scoop_01\scoopg\apps\wezterm\current\wezterm_modules/features/init.lua'
        no file 'C:\Users\gana\.config\wezterm/features.lua'
        no file 'C:\Users\gana\.config\wezterm/features/init.lua'
        no file 'C:\Users\gana\AppData\Roaming\wezterm/plugins/features/plugin/init.lua'
        no file 'C:\Users\gana\.wezterm/features.lua'
        no file 'C:\Users\gana\.wezterm/features/init.lua'
        no file 'C:\vol\scoop_01\scoopg\apps\wezterm\current\lua\features.lua'
        no file 'C:\vol\scoop_01\scoopg\apps\wezterm\current\lua\features\init.lua'
        no file 'C:\vol\scoop_01\scoopg\apps\wezterm\current\features.lua'
        no file 'C:\vol\scoop_01\scoopg\apps\wezterm\current\features\init.lua'
        no file 'C:\vol\scoop_01\scoopg\apps\wezterm\current\..\share\lua\5.4\features.lua'
        no file 'C:\vol\scoop_01\scoopg\apps\wezterm\current\..\share\lua\5.4\features\init.lua'
        no file '.\features.lua'
        no file '.\features\init.lua'

        can't load C modules in safe mode
stack traceback:
        [C]: in function 'require'
        [string "C:\vol\scoop_01\scoopg\persist\wezterm\wezter..."]:4: in main chunk

One could say I should place the features.lua in any one of all these other places.
But my intention is to manage my wezterm configuration in the scoopg/persists/wezterm folder.
It seems logical that related configuration files should also be there.

It's a bad idea to place it along with the wezterm binary in scoopg/apps/wezterm/current/wezterm_modules because, scoop deletes and recreates that folder whenever there is a wezterm update.

I came up with a workaround described in next comment, but it seems kludgy.

To Reproduce

  • use environment variable to specify wezterm.lua folder
  • create a module 'features.lua' in same folder
  • use require "features" and see if require succeeds

Configuration

local features=require "features" ;

Expected Behavior

when WEZTERM_CONFIG_FILE is specified, perhaps the config dir path search should include wezterm.config_dir

Logs

PS C:\Users\gana> dir $env:WEZTERM_CONFIG_FILE


    Directory: C:\vol\scoop_01\scoopg\persist\wezterm


Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
-a----         6/17/2024  11:51 PM           5240 wezterm.lua

Anything else?

Ref

@hgkamath hgkamath added the bug Something isn't working label Jun 17, 2024
@hgkamath
Copy link
Author

hgkamath commented Jun 17, 2024

workaround:
point .config/wezterm to the persists\wezterm folder, seems kludgy

PS C:\Users\gana\.config> cmd /c "mklink /J wezterm C:\vol\scoop_01\scoopg\persist\wezterm" 

junctioning the wezterm config directory achieves the same effect as WEZTERM_CONFIG_FILE environment variable.
The more I think about it, I wonder why, I had originally set up to use the WEZTERM_CONFIG_FILE way of loading the wezterm lua in the first place.
The most plausible reason is that I have a dual boot machine windows linux, with admin and unprivileged user that is accounts, I think I was trying to avoid having to make and manage 4 configurations in 4 places, and sometimes I swap entire OS partitions placed in VHDX files. So I put the wezterm.lua in an accessible place outside of the private user folder and also outside the C:\ file system. C:\vol\scoop_01 is a mount point of a VHDX, the VHDX itself residing on a different partition

The config file can also be provided by the command line --config-file argument. The docs say the command line take precedence over the environment variable. Maybe even for this case the config directory should be set similarly ?

Q) When would one prefer to use the environment variable method over a filesystem junction method?
A) maybe when (a) filesystem does not have junctions, (b) unprivileged user by OS group policy not allowed to create junctions.

@wez
Copy link
Owner

wez commented Jul 13, 2024

I'm not really clear on what you're doing, but I do want to note that you can put something like this at the top of your main wezterm.lua file (the one that WEZTERM_CONFIG_FILE points to):

local wezterm = require 'wezterm'
package.path = package.path .. ";" .. wezterm.config_dir .. "/?.lua"

You can arbitrarily change package.path to match your environment.

@hgkamath
Copy link
Author

hgkamath commented Jul 16, 2024

Thanks for your reply and for wezterm

  • I'm not really clear on what you're doing

    • Motivation for setting things up the way I did.
      • My machine is setup to do dualboot, multiboot. There was a time when I was reinstalling/trying-out various WinOS and Linux Distributions on my laptop. Presently, I now have about 3 commonly used multi-boots: Win10, Win11, Linux. There are virtual machines also., and I can boot into liveiso-s using ventoy.
      • At one time I wanted a zero-configuration way to use wezterm, so that I don't have to copy or setup up the config directory of various ephemeral newly setup operating systems. Doing otherwise is tedious.
      • Copying the configuration to multiple places requires having a method to keep track of changes. You could say why not use a vcs like git, I hadn't thought of that, and still haven't got around to taking the initiative to do that.
      • Setting a Environmental variable is easy, and can even be done by a ansible script.
      • Saving things outside of the OS partition means not having to worry about backing things up when removing a OS, or setting things up after installing.
      • The WEZTERM_CONFIG_FILE lends itself as a easy way to do the above.
      • The reason I hadn't run into this earlier is because so far my wezterm config was self contained and had not modularized it to rely on files sourced from outside the main config file, as was recommended by reddit link I had included
  • package.path

    • Okay, I hadn't thought aboutpackage.path
    • I am not proficient in a lua and it hadn't occurred to me that it was in-user-script modifiable.
    • The 2 docs below use the phrase "The Lua package.path is configured with the following paths" , so that made me think it was a preset.
    • This could be a sufficiently usable workaround.
    • If this is the recommended way to do set the module search path, then one may close this bug.

Ref :

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants