search

archlinux / archinstall

Arch Linux installer - guided, templates etc.
GNU General Public License v3.0
6.37k stars 548 forks source link

Add manual-insert option to some fields #1159

Open Torxed opened 2 years ago

Torxed commented 2 years ago

Something that has gotten "lost in translation" is the ability to freely input things into fields like the mirrors, profiles and probably some other ones.

I'd like to petition that we bring back via i or something on certain fields, which will bring the user to a manual input field. That way, things like profiles can be entered not from a pre-defined list but any URL to the users liking.

It's not a huge priority as we can still manually edit the JSON conf and send it to --config but it would be ideal for the first time generating the JSON conf.

svartkanin commented 2 years ago

What would that input for the profiles look like though?

Couldn't that be "solved" with the additional packages to install?

Torxed commented 2 years ago

It could just be a input("...") that populates {"profile": x} :) But i have an additional idea that it could also populate the profile list cache, for future multi-select pf profiles and in that case not only inserts it but selects it

svartkanin commented 2 years ago

@Torxed this should be (partly?) solved now with all the changes in https://github.com/archlinux/archinstall/pull/1434

Torxed commented 2 years ago

Partially yes. I still lack the following: screenshot

On this step, we used to be able to straight up start writing as every menu/question was just a simple input() call. And based on the input, if it was Sweden we could match that against the list of known regions and thus collect all the mirrors from that region and use those. If it started with http* we used the input as-is as the mirror definitions.

This type of free-text input was very useful to do stuff that most people wouldn't do.. But those of us that required special cases like offline or local mirrors could input that in the mirror "region" field.

Profile was the same thing. Since the listing of profiles is done by looking up the locally installed profiles we can only select those. But archinstall can actually support loading profiles remotely.

screenshot

So in this menu, we loose the ability to free-text insert a profile name that archinstall can either load directly because it starts with http*. But also use the fall-back upstream check where archinstall goes to github and tries to find the given profile name by checking https://raw.githubusercontent.com/archlinux/archinstall/master/profiles/<free text input given>.py.

It's not a huge pain in the but, but it's a bit limiting that we can't enter free-text on any of the fields anymore. So a hidden i press to enter a classic old input()-style for the value to the menu item would be pretty neat :)

svartkanin commented 2 years ago

Yeah the mirror one is a regression, and should be changed to allow entering a custom one but it will add another submenu then :(

On the profile selection, i saw that there's an option to fetch from github but i was rather confused about the purpose, as the local profiles will be the same? I'm not a massive fan of letting users enter a predefined profile with free text because it creates quite some handling for that and especially when the options are distributed into submenus :/

Torxed commented 2 years ago

Yeah the mirror one is a regression, and should be changed to allow entering a custom one but it will add another submenu then :(

On the profile selection, i saw that there's an option to fetch from github but i was rather confused about the purpose, as the local profiles will be the same? I'm not a massive fan of letting users enter a predefined profile with free text because it creates quite some handling for that and especially when the options are distributed into submenus :/

The reasoning behind is that I for instance have a https://hvornum.se/laptop.pyprofile that I don't wish the world to get listed, but I'd like to use. Nowdays I just enter it in a --conf {"profile": "https://..."} :) So it's a low priority but i't be nice to get back in a descreet way :)

svartkanin commented 2 years ago

That's fine, I kept the functionality to be able to provide a url/local path to load modules. The thing I was confused about was, why were also going to github explicitly to load the profiles from there whereas they are present in the installation anyways?