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

Feature Request/Proposal: Set up preferred shell #246

Open
Sharkitty opened this issue Apr 7, 2024 · 11 comments
Open

Feature Request/Proposal: Set up preferred shell #246

Sharkitty opened this issue Apr 7, 2024 · 11 comments

Comments

@Sharkitty
Copy link

Description

Adding a script usable by either just and/or yafti that should be able to let users choose their preferred shell, and set it up.

The minimum implementation I would need is setting up zsh and omz in this way:

  • Checking if zsh is installed. If it's not, proposing the user to install zsh as a layered package.
  • Propose the user to run ohmyzsh install script.

But I think it would make sense to extend this idea so users could choose any shell they want and the script would set it up.

I can work on this script, at least as far as the zsh part go. For further contribution it depends on the time I have.

@castrojo
Copy link
Member

castrojo commented Apr 7, 2024

We have ujust chsh zsh already. I think this should probably be ujust oh-my-zsh or perhaps an option step after the ujust chsh zsh to toggle oh-my-zsh on and off.

@Sharkitty
Copy link
Author

We have ujust chsh zsh already. I think this should probably be ujust oh-my-zsh or perhaps an option step after the ujust chsh zsh to toggle oh-my-zsh on and off.

I missed this script ^^' But it just sets the login shell. So it could be a separate script called ujust omz or ujust ohmyzsh (or both). But I could also make something like ujust chsh zsh --ohmyzsh and if it's not specified it asks the user "do you want to use ohmyzsh framework?"

Shouldn't it be a script that ujust just calls so it can be used by yafti as well?

Agreed on making it a toggle however!

@castrojo
Copy link
Member

castrojo commented Apr 7, 2024

Yeah a standalone script in /usr/libexec would do the trick, that way we can call it from ujust and from yafti.

@noelmiller
Copy link
Member

The only response I have is I'm not sure this would belong in config? I can see something like this being beneficial in Bluefin DX, but not so much in Bazzite or other downstreams not focused on development.

@Sharkitty
Copy link
Author

The only response I have is I'm not sure this would belong in config? I can see something like this being beneficial in Bluefin DX, but not so much in Bazzite or other downstreams not focused on development.

I don't really see how that could negatively affect Bazzite or other downstreams. ujust recipes don't do anything unless they are called, and its use in yafti would of course be optional. There are already ujust recipes that aren't necessary in non-development images in this repository. The point of this feature would be to make it simpler to install omz for users who want to use it. Users who don't change their default shells would remain unaffected.

@castrojo
Copy link
Member

castrojo commented Apr 9, 2024

I've noticed a large amount of shell diversity in our community.

I think letting each shell subcommunity hook up their own little config setups and stuff is fine -- people dig oh-my-zsh, I don't think it hurts to have it in config.

If people decide otherwise then I'll 100% take it in Bluefin!

@bsherman
Copy link
Contributor

I would agree that OMZ is a good fit for aurora/bluefin/bazzite ... but this my general concern with config echoes @noelmiller's above...

In general, I don't think we have a clear guide to when it is appropriate to add things for those downstreams to the config since it's also pre-installed on main/hwe images.

@castrojo
Copy link
Member

Ok, I'll take this in bluefin then Sharkitty if you wanna PR it there!

@Sharkitty
Copy link
Author

I hear the concerns. However, I feel like what's suggested here is to duplicated the same code in multiple downstreams. And that doesn't seems like a great way to handle this. Bringing the feature upstream would have allowed diverging downstreams to all benefit from the same code without having to re-implement it (And all it implies if there's a need for fixes or enhancements down the line).

If upstream doesn't want this feature. Too bad, but I understand. I would appreciate however if a better solution could be found.

@bsherman
Copy link
Contributor

If upstream doesn't want this feature. Too bad, but I understand. I would appreciate however if a better solution could be found.

I appreciate your contribution here, it just happens to come at a time when I've been pondering how we scope things for different use cases, while not being TOO opinionated in the core "main" images.

I've created this proposal as a way in which we could include your contribution in config but still keep it scoped to use in Aurora/Bluefin/Bazzite (or custom images which choose to add it).

@Sharkitty
Copy link
Author

I've created this proposal as a way in which we could include your contribution in config but still keep it scoped to use in Aurora/Bluefin/Bazzite (or custom images which choose to add it).

This is a very interesting proposal. It makes a lot more sense this way. I think going with this idea is the best course of action here.

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