linutil
linutil copied to clipboard
[Discussion] Implementing Local Installation and Update Mechanism for Linutil
Local Installation of Linutil
Context:
Since GitHub discussions aren't enabled yet, this issue will serve as a discussion forum.
Subject:
Enable local installation of Linutil for users.
Motivation:
Users who rely on offline commands like Display, Bluetooth, and Wi-Fi tools shouldn't have to download Linutil each time they use it.
Suggestion:
Implement Local Installation:
Two possible approaches:
- Provide a shell script for setting up Linutil locally.
- Add an installation option within Linutil itself:
- A menu item or a pop-up on the first run.
Installation Directory:
Install Linutil in a user-defined directory, with $HOME/.linutil as the default. A pointer to this directory could be stored in $HOME/.local/share/linutil to allow customization. This setup would also enable persistent storage for user preferences, like disabling the initial installation prompt.
Executable Path Example:
$HOME/.linutil/versions/2024.08.19/bin/linutil
A symlink to the current version would be created in $HOME/.linutil/bin/linutil. The user would be prompted to add $HOME/.linutil/bin to their $PATH.
Local Update Mechanism:
If Linutil is installed locally, it could check for updates in the background. If an update is available, users could be notified and given an option to update. The new version would be downloaded to the appropriate versions folder, the symlink updated, and the user prompted to keep or delete the old version. This approach ensures stability, allowing fallback to previous versions if issues arise.
Discussion:
Please share your thoughts and suggestions here before we move forward with implementation.
Tagging: @ChrisTitusTech @lj3954 @JustLinuxUser
I think its an interesting idea, but I would like to challenge the premise that the user want linutil installed on its machine.
To me, it sounds like there would be more value for the user to have a copy of the script on its machine, so he can execute it directly with its own alias, modify it and even learn from it, rather than launch the TUI every time he wants to access it.
This adds some control for the user that can now have a personal version of some of the scripts, while getting the latest version of the TUI and the new or updated scripts.
This also opens the way for new abilities for linutil. Like creating alias from the TUI and linking them to a script directly.
Unsure about the usefulness of that one, but hey, it's an idea :)
@SoapyDev I am suggesting this mainly because of the ability to use offline tools. If a user starts using Linutil to manage their displays, bluetooth, Wi-Fi , etc, they would not want to have to download a script from the internet every time. It's wasted time waiting and it's impossible on a no connection scenario. I think it's nice to be able to launch it instantly to change some stuff on your display, rather than wait up to 10 seconds for it.
Yes, I agree, but what I am trying to say is, do they want linutil, or the actual script. Wouldn't it be better if they could install the script directly on their machine and execute it / modify it / learn from it.
So what I am proposing is that, rather than installing the whole thing, they can install a copy of the scripts they want from linutil. This removes the requirement to re-download the utility every time they want to use the Bluetooth script, as they will posses it.
Unsure if I am clear. English is a second language, so don't hesitate to ask me for clarification if I am not. :)
@SoapyDev I understand that. My question is. Is it worth it to have a lot of work to implement that, when they could just launch the tool and choose the correct command? I think it's overcomplicating it.
This is a good question @afonsofrancof.
I think that, as its right now, the additional worth added would fall short of the effort needed. I mean, Bluetooth, WiFi and screen direction are nice script, but not worth that amount of work.
In the long run, as we get more script that add value, I think it might be well within its worth.
But this is speculative. Yet, this is also for Linux, so not expecting some amazing stuff coming in, would be blind-sighted.
I guess, this is more of a Mission, Vision, Values directed decision. Never the less, in both case, the user is winning :)
I think it would be worth it as we add more applications to linutil. Instead of running curl every time to configure something ( For example gaming deps and after a couple of minutes for bash or something like that ), it would be faster if it was run locally.
Right now it would not be worth it but when linutil grows larger it would be best to implement installation of linutil.
Having bluetooth wifi controls is not necessary. But more users struggle to set up their monitors especially when it comes to multi-monitor setup with various display modes. I personally think leaving the monitor set-up script in there would be beneficial for the new comers to linux
#333
#333
AUR looks good ! The crate is still not published, right?
The crate is still not published, right?
It will be today / tomorrow. You can then do cargo install linutil or cargo binstall linutil.
The crate is still not published, right?
It will be today / tomorrow. You can then do
cargo install linutilorcargo binstall linutil.
Nice! I had completely forgotten that we can just use crates hahaha It's a much better solution
Nice! I had completely forgotten that we can just use crates hahaha It's a much better solution
The only issue with packaging on crates.io is that users that already have a version installed and there's a new release, don't have a "simple" way to update. https://stackoverflow.com/questions/34484361/does-cargo-install-have-an-equivalent-update-command So I'd say installing from crates.io is not recommended.
The only issue with packaging on crates.io is that users that already have a version installed and there's a new release, don't have a "simple" way to update. stackoverflow.com/questions/34484361/does-cargo-install-have-an-equivalent-update-command So I'd say installing from crates.io is not recommended.
Ah, got it. But I think it's so much simpler than my solution that it's worth it.
Implemented in #526. /close