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

Non-interactive, quiet and offline modes for the installer script #56

Open
pluiedev opened this issue Mar 8, 2024 · 5 comments
Open

Comments

@pluiedev
Copy link

pluiedev commented Mar 8, 2024

Currently, the installer relies on a lot of user input that might not be available in an automated install environment. For example, currently in Nixpkgs, it is necessary to manually patch the installer script to remove interactivity so that the builder does not hang while waiting for input from stdin via read.

In addition, there are also lots of print-outs and clear screens that are just completely unnecessary for a non-interactive environment, and I find that adding a --no-interactive flag would make downstream packagers' lives much easier, especially since the patch does not have to be updated with each change to the script. A -q/--quiet flag would also be nice to suppress all non-critical messages so that the build log does not get cluttered with unnecessary prompts.

Finally, this is kind of a Nix-specific thing, but it would be nice if we can use a local copy of the cursors repo, instead of wgeting it from the internet. This is mostly done to improve reproducibility and make sure that the cursors can be easily updated and verified to work, and to remove a dependency on wget. This is not as important as the first two flags, but it would be very nice to have.

@Sourcastic
Copy link
Member

This is a great suggestion, thank you. I'll probably end up modifying the debug feature similar to what I think the nixpkg is doing and add the relevant flags. As for adding the cursor, I don't know how the org would feel about hosting another Catppuccin port as a part of this one (Assuming I understand what you mean). So that's a little more difficult to do.

Though... for now, I'd want to get the KDE6 update done first, and I think this is something to work on after.

@pluiedev
Copy link
Author

As for adding the cursor, I don't know how the org would feel about hosting another Catppuccin port as a part of this one (Assuming I understand what you mean). So that's a little more difficult to do.

Nono, I mean using a local path to a cloned copy of the cursors repo when building, so that we can clone a known revision of the cursors repo, and then run the installer with the existing repo, without having it run wget.

@GiggleSquid
Copy link

A note on the catppuccin cursors:

It may be better to add a flag to disable installation rather than packaging them with the KDE theme as pluiedev said (For our nix use case at least). The way we're currently moving to implement catppuccin themes can just have the cursors as a separate source.

So if we could just pass say --no-cursors to the install script in a non-interactive and quiet mode, I think this would be the better option.
This would also just be beneficial for people who may not like the cursor set anyway and who may not want it installed at all

@pluiedev
Copy link
Author

A note on the catppuccin cursors:

It may be better to add a flag to disable installation rather than packaging them with the KDE theme as pluiedev said (For our nix use case at least). The way we're currently moving to implement catppuccin themes can just have the cursors as a separate source.

So if we could just pass say --no-cursors to the install script in a non-interactive and quiet mode, I think this would be the better option.

This would also just be beneficial for people who may not like the cursor set anyway and who may not want it installed at all

To be honest the cursors should just be their own thing. It's not like they're specific to KDE in any way

@Cequallium
Copy link
Contributor

Currently, the installer relies on a lot of user input that might not be available in an automated install environment. For example, currently in Nixpkgs, it is necessary to manually patch the installer script to remove interactivity so that the builder does not hang while waiting for input from stdin via read.

In addition, there are also lots of print-outs and clear screens that are just completely unnecessary for a non-interactive environment, and I find that adding a --no-interactive flag would make downstream packagers' lives much easier, especially since the patch does not have to be updated with each change to the script. A -q/--quiet flag would also be nice to suppress all non-critical messages so that the build log does not get cluttered with unnecessary prompts.

I completely agree with you on this, I'll work on it.

Finally, this is kind of a Nix-specific thing, but it would be nice if we can use a local copy of the cursors repo, instead of wgeting it from the internet. This is mostly done to improve reproducibility and make sure that the cursors can be easily updated and verified to work, and to remove a dependency on wget. This is not as important as the first two flags, but it would be very nice to have.

I tried using sub-modules to get around this and it isn't viable (The download is way too big),
I think using a flag is best idea as its not that integral anyway.

Thank you for your suggestions.

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