[Bug]: Installation of CSV Folder plugin fails on Windows 10

[UmeshOnAI]

Describe the bug

I have tabularis installed on Windows 10 in D drive. When trying to install csv plugin (either version), the Win32 error crops up. My Python is properly installed with proper path configuration. Screenshot attached

To Reproduce

1: Launch tabularis
2: Go to plugins
3: Click on Install button for CSV Folder plugin

OS Version

Window 10

Tabularis Version

0.9.5 (Beta)

Relevant Log Output

[debba]

Hi @UmeshOnAI ,
I have a suspect about this issue .

I made a mistake here at the beginning https://github.com/debba/tabularis-csv-plugin/blob/main/plugin.py
I added the shebang, but it's ignored in Windows ( #!/usr/bin/env python3 ).
I will check and fix soon.
Thanks a lot for feedback.

[UmeshOnAI]

Based on reading from debba
tabularis-csv-plugin repo, I copied debba/tabularis/data/plugins/csv folder from C:\Users\MeUser\AppData\Roaming to D:\Users\MeUser\AppData\Local and it shows the plugin installed after restart. So I think the app by default downloads the plugin in C drive but then because it is installed in D drive, takes the relative reference of D drive from installation and fails to find the plugin. This is based on my read of src-tauri/src/plugins/installer.rs

[debba]

@UmeshOnAI mm interesting, probably there are a mix of bugs.
I am not a windows user, I will check for sure, but I need to understand better windows environment.
If you find something interesting or you want fix the issue, go ahead.

[UmeshOnAI]

The two solutions could be:

1. Rewrite of get_plugins_dir() to the following:

use tauri::api::path::resolve_path; use tauri::Env; // ... pub fn get_plugins_dir() -> Result<PathBuf, String> { let context = tauri::Context::from_env(Env::default()); // Adjust as needed in Tauri context let app_dir = resolve_path(&context.config(), &context.package_info(), &Env::default(), ".", None) .map_err(|e| format!("Failed to resolve app dir: {}", e))?; let plugins_dir = app_dir.join("plugins"); if !plugins_dir.exists() { fs::create_dir_all(&plugins_dir) .map_err(|e| format!("Failed to create plugins directory: {}", e))?; } Ok(plugins_dir) }

2. Create a optional portable mode support (e.g., via env var like TABULARIS_DATA_DIR)

Will try both in a couple of days on the fork.

[debba]

@UmeshOnAI Sounds good. two notes:

The approach of 1) looks fine; we just need to make sure it runs only on Windows, since Unix/Unix-like systems are not affected (path conventions are completely different).

The root cause of your issue is that Windows cannot determine the interpreter. By the way, the problem also affects Linux/Mac, because the shebang allows execution as a Python script via #!/usr/bin/env python3, but the user may have Python installed in different paths.
I'm thinking of allowing users to assign the interpreter in a Plugin Settings area.
We could also try to infer it by default, but letting the user select their own interpreter seems reasonable to me.
Any plugin that requires an interpreter could optionally declare it in the manifest.json (to avoid breaking changes). Overriding it in the Plugin Settings would allow the script (Python, PHP, etc.) to be executed at runtime using the correct interpreter.

What do you think?

[UmeshOnAI]

Yeah, I have been thinking about that as well. It is not just the plugin directory issue but python installation as well. The best would be to provide python interpreter path in settings area. It can be pre populated with what can be inferred but then gives user a possibility to modify as there may be multiple installations of python also (for various reasons). It is true in my case on my Windows, Linux and Mac machines where I have multiple python versions based on the projects etc.

BTW, kudos to you. Great work. World thanks you for your O/S contribution.

[debba]

@UmeshOnAI

If you are interested in contribute, I’ve created a planning document with Claude Code:

plugin-settings-interpreter.md

You can also reach me on Discord if you prefer (you’ll find the link in the project’s README).

Thank you very much for what you wrote.
This product has been on my mind for quite some time and I mainly built it to solve one of my own needs.

Until a few years ago, it would have been unthinkable to build something like this in my spare time, but now AI provides great support that allows us to iterate and keep developing.

I’m really happy that it’s being appreciated, and even more so that contributors are starting to show up. There are surely many people with a lot of experience who can help make it really interesting and also fix the large number of bugs that still exist.

If you like the project, feel free to help spread the word as well, more people get involved, more we’ll be able to improve it. 🚀

[debba]

@UmeshOnAI

I made the integration for interpreter settings in Plugins.
It's accessibile through Gear icons inside plugins and doesn't add any breaking changes in plugins.

Can you do a check in new release?