feat: Allow for inclusion of scripts written in more capable languages

[lj3954]

Is your feature request related to a problem? Please describe.

Some useful scripts or tools may be too complicated to feasibly be written in POSIX languages.

Describe the solution you'd like

Include a 'language' field (defaulting to shell) in the tab data for script entries. Python would be a rather simple addition, given that it's very commonly used and is interpreted, although other languages, including compiled languages through build steps, could be added later down the line (though, of course, binary size and build times would be negatively impacted).

Checklist

• I checked for duplicate issues.
• I checked already existing discussions.
• This feature is not included in the roadmap.

[adamperkowski]

I agree with your point here, but

• Most Python scripts can be perfectly done in sh with use of curl or other lightweight binaries.
• This (especially in case of Python) would affect perfomance
• I can't think of anything we would need Python or any language other than sh (and Rust) for

I know that this could improve contributors' experience a lot, but there are obvious downsides.

[lj3954]

Most Python scripts can be perfectly done in sh with use of curl or other lightweight binaries.

Python includes a standard library that provides functionality that's difficult or impossible to achieve with software installed on most systems. The syntax of the language is also superior to what's available in POSIX, so the maintainability of scripts can be improved.

This (especially in case of Python) would affect perfomance

I'm not sure how including Python scripts would hurt performance. Python is typically more performant than a shell, and we can obviously hide the entries if Python isn't installed (much like with command_exists precondition).

I can't think of anything we would need Python or any language other than sh (and Rust) for

Rust is exclusively used for the TUI. Scripts in the project are exclusively shell scripts, which comes with major limitations. Whether or not a different language will ever be strictly necessary doesn't mean there's no point adding the option; maintainability is quite important.

[nnyyxxxx]

i don't agree with adding python, everything you can do in a linux system you can do with shell scripting, i dont see why we would need to make scripts with python as well.

[adamperkowski]

Python includes a standard library that provides functionality that's difficult or impossible to achieve with software installed on most systems.

I know Python, POSIX, and shell scripting perfectly well.

Rust is exclusively used for the TUI. Scripts in the project are exclusively shell scripts, which comes with major limitations.

No one says we can't use Rust for various functionality and menu entries too.

[lj3954]

No one says we can't use Rust for various functionality and menu entries too.

Maintaining this while using TOML files for all tab-related data would be quite difficult. Adding other scripting languages wouldn't be anywhere near as difficult.

[nnyyxxxx]

No one says we can't use Rust for various functionality and menu entries too.

Maintaining this while using TOML files for all tab-related data would be quite difficult. Adding other scripting languages wouldn't be anywhere near as difficult.

it's best we keep it shell, and rust for now, i dont think Chris will like adding python to mimic shell scripting

[Real-MullaC]

@lj3954 There is no point changing toml to python as if you look at the roadmap here we will be re doing it all to GUI and scrapping CLI. So there is no point implementing this.

[lj3954]

@lj3954 There is no point changing toml to python as if you look at the roadmap here we will be re doing it all to GUI and scrapping CLI. So there is no point implementing this.

I have no idea what you're talking about, to be completely honest. I'm talking about adding an option for script developers to write their scripts in python, if they choose, rather than shell. The TOML format will be preserved, which is why the idea of writing script functionality in Rust is not really in the picture.

[nnyyxxxx]

@lj3954 There is no point changing toml to python as if you look at the roadmap here we will be re doing it all to GUI and scrapping CLI. So there is no point implementing this.

I have no idea what you're talking about, to be completely honest. I'm talking about adding an option for script developers to write their scripts in python, if they choose, rather than shell. The TOML format will be preserved, which is why the idea of writing script functionality in Rust is not really in the picture.

python is not needed? you can do every task on linux with shell scripting, adding an option for developers to write scripts in python will ruin maintainability.

[lj3954]

@lj3954 There is no point changing toml to python as if you look at the roadmap here we will be re doing it all to GUI and scrapping CLI. So there is no point implementing this.

I have no idea what you're talking about, to be completely honest. I'm talking about adding an option for script developers to write their scripts in python, if they choose, rather than shell. The TOML format will be preserved, which is why the idea of writing script functionality in Rust is not really in the picture.

python is not needed? you can do every task on linux with shell scripting, adding an option for developers to write scripts in python will ruin maintainability.

"Every" task being possible is flat out untrue, and there are several cases already where being able to use a different language would likely improve the maintainability of that specific script (especially with a language like Python, which nearly every contributor will have at least a reasonable level of knowledge of).

The maintainability of the overall project likely wouldn't be changed much; the given script would just be executed through python/python3 rather than sh. #489 could be resolved alongside this.

[nnyyxxxx]

@lj3954 There is no point changing toml to python as if you look at the roadmap here we will be re doing it all to GUI and scrapping CLI. So there is no point implementing this.

I have no idea what you're talking about, to be completely honest. I'm talking about adding an option for script developers to write their scripts in python, if they choose, rather than shell. The TOML format will be preserved, which is why the idea of writing script functionality in Rust is not really in the picture.

python is not needed? you can do every task on linux with shell scripting, adding an option for developers to write scripts in python will ruin maintainability.

"Every" task being possible is flat out untrue, and there are several cases already where being able to use a different language would likely improve the maintainability of that specific script (especially with a language like Python, which nearly every contributor will have at least a reasonable level of knowledge of).

The maintainability of the overall project likely wouldn't be changed much; the given script would just be executed through python/python3 rather than sh. #489 could be resolved alongside this.

ok, give me solid examples to back up what you're saying. Until then stop lying about it.

[adamperkowski]

"Every" task being possible is flat out untrue, and there are several cases already where being able to use a different language would likely improve the maintainability of that specific script (especially with a language like Python, which nearly every contributor will have at least a reasonable level of knowledge of).

As I said, it may be slightly easier to maintain, but it's going to be another dependency for linutil and will cost us performance / UX.
I think every contributor has or should have a reasonable level of knowledge of shell scripting.

The maintainability of the overall project likely wouldn't be changed much

You just stated the opposite...

[lj3954]

As I said, it may be slightly easier to maintain, but it's going to be another dependency for linutil and will cost us performance / UX.

Once again, much like the command_exists precondition option, we can just hide Python scripts when the dependency isn't present. Also, nearly every system has Python installed, it's ubiquitous.

You just stated the opposite...

The maintainability of individual scripts, written in a language with better syntax and builtin functions, would be improved. The maintainability of the overall project (including the TOML files, Rust code, etc) would not be impacted much in order to benefit from these improvements. With the latter being the case (which I can assure you is true), there's essentially no downside to including this option for script developers who'd like it.

[ChrisTitusTech]

Ok lets shut this down before it escalates. I like the ability to add languages in the future, but right now I don't see a use case that isn't covered under our current setup.

Lets work on getting the stuff we have polished before we add more languages with will invite more PRs from python folks. I'm not ready to add this change yet, but we can look at it in the future when we have everything working well in it's current state.

[adamperkowski]

@ChrisTitusTech you can close the issue as not planned

[adamperkowski]

/close not planned

[lj3954]

"I like the ability to add languages in the future, but right now I don't see a use case that isn't covered under our current setup."

This is an incorrect closure reason.

[adamperkowski]

@lj3954 This is far from completed. Should be closed as not planned in my opinion.

[lj3954]

Completed is the most generic closure reason available here. I feel as though 'not planned' is more typically used for ideas which are out of scope of a project, not just those that are off the table for the time being.

Typically in cases like this you'd just leave this issue to rot until the problem is ready to be addressed, but with the history of, well, quite heated discussion in this project, I agree with Chris that it's better to just close it out.

[nnyyxxxx]

coming back to this months later, i agree that the scripts should be rewritten in a better lang like python, but would any of us actually want to write python? no. But same goes for bash, so it negates that.