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

[Discussion] Implementing Local Installation and Update Mechanism for Linutil #180

Closed
afonsofrancof opened this issue Aug 19, 2024 · 14 comments

Comments

@afonsofrancof
Copy link
Collaborator

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:

  1. Provide a shell script for setting up Linutil locally.
  2. 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

@SoapyDev
Copy link
Contributor

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 :)

@afonsofrancof
Copy link
Collaborator Author

@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.

@SoapyDev
Copy link
Contributor

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. :)

@afonsofrancof
Copy link
Collaborator Author

@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.

@SoapyDev
Copy link
Contributor

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 :)

@jeevithakannan2
Copy link
Contributor

jeevithakannan2 commented Aug 20, 2024

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.

@jeevithakannan2
Copy link
Contributor

jeevithakannan2 commented Aug 20, 2024

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

@adamperkowski
Copy link
Collaborator

#333

@afonsofrancof
Copy link
Collaborator Author

#333

AUR looks good !
The crate is still not published, right?

@adamperkowski
Copy link
Collaborator

The crate is still not published, right?

It will be today / tomorrow. You can then do cargo install linutil or cargo binstall linutil.

@afonsofrancof
Copy link
Collaborator Author

The crate is still not published, right?

It will be today / tomorrow. You can then do cargo install linutil or cargo binstall linutil.

Nice!
I had completely forgotten that we can just use crates hahaha
It's a much better solution

@adamperkowski
Copy link
Collaborator

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.

@afonsofrancof
Copy link
Collaborator Author

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.

@adamperkowski
Copy link
Collaborator

Implemented in #526.
/close

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants