They are quite buggy atm. Plz fix thnks

Split ginst in the following components:

• lib (core functionality)
• cli (command line io) which uses lib
• tui (terminal user interface io) which uses lib

Each of which can be their own repo.

This enables cleaner development since the tui version can be developed seperately and doesn't need to interfere with other ginst parts.

Output is not displayed correctly

The tool should have some way of registering and executing configuration steps. Configurations can behave like the Programm struct currently, meaning they can be either standalone or be related to a programm.

Is your feature request related to a problem? Please describe.
To abide by the unix philosophy (which i like) I think it would be useful to have a quick command to print out the status of the (not) installed programs

Describe the solution you'd like
Something like -s/--status or -l/--list

Is your feature request related to a problem? Please describe.
Manually rewriting the programs file is painful atm and serde already has everything in place

Describe the solution you'd like
Maybe something like a -o option to output it into the desired file type

Describe alternatives you've considered
Pain and suffering

Try implementing the Sublistable as a generic trait like this:

trait Sublistable<T: Sublistable + Clone>{
    type OwnType: T;
    [...]
}

and then have the Programmable trait implement it for itself:

trait Programable: Sublistable<Programmable> + Clone {
    ...
}

Afaik the previous iterations didn't work because the function defined in the Sublistable trait had a return value of a Sublistable type which didn't implement the clone trait.

Through this construct it should now be clear that the return type should be any type that does implement the sublistable type AND also implements the clone type.

Since Programmable does fulfill both of those traits it should work.

The only other error that was in my way then was the compiler not knowing the size of the return value at compile time. That should probably happen again but I'll see what the dyn keyword is for. Maybe that will fix it.

Describe the solution you'd like
Be able to call ginst like:

cat programs | ginst install all

Describe alternatives you've considered
The alternative is calling ginst with the file needed like:
ginst install all programs.yaml
Which means that you need the programs file on the machine.

Idealy you could get file contents from a file on some remote server and still use ginst without having to download the file itself.

Problem

The config syntax has too much boilerplate for my taste. It's hard to write and maintain and small changes break everything.

Improvement

Just write down the program names.
Have the programm/package names from top down.

This way you have dependency management simply by writing the dependencies first.

Example:

gcc
fish
rustc
cargo

Will install all those packages from top down.

It will consult the package manager for names and versions and will install exact matches or list if there are multiple matches.

Further feature ideas would be:

• Versioning like: gcc >= x.y will install only if gcc has a version newer than x.y.

Drawbacks

1. Less control
   This leads to a less explicit config. I'm honestly not sure if you can somehow still define a custom installation method this way.
2. Split configs
   ginst would have to support both the old and new config version which could lead to confusion.

Is your feature request related to a problem? Please describe.
Currently executing instructions only works in bash. That isn't really a problem since bash is basically everywhere BUT wouldn't it be nice to let the user execute their scripts in, i dunno like zsh or fish or the windows command prompt? Not sure why you would use cmd but who am i to judge.

Describe the solution you'd like
ginst --shell=SHELL --file ...

Describe alternatives you've considered
It is currently possible to work around this issue by using something like fish -c "..." in the install/config steps but in environments where bash isn't available this doesn't help either.

Additional context
/

Is your feature request related to a problem? Please describe.
When there are no installation instructions available ginst is generally pretty useless. I'd like that to change and for it to seek other ways of finding a solution.

Describe the solution you'd like
Let it search the lokal PM's (multiple if there are multiple) for available packages and display relevant info like name, version and so on and let the user decide if they want to install.

Describe alternatives you've considered
The alternative would be that ginst doesn't provide further help. I could understand that users may not want this feature so maybe have an option or a configuration file where they can disable this behaviour.

Additional context
Will add a new Issue for config options.

Is your feature request related to a problem? Please describe.
For not only changing the behaviour temporary it would be nice to be able to change the behaviour permanently through config files.

Describe the solution you'd like
Let ginst search in multiple places for a config file. Either in
/etc/ginst/config.ginst
or
~/.config/ginst/config.ginst

Describe alternatives you've considered
Manually setting options every time.

Additional context
Ill add an option list later

This is a needed feature for users that didn't read the wiki or something before executing.

Perhaps on the bottom of the screen.

Maybe add h as help key displaying a usage window?

Saw a post on r/unixporn that had a really nice installer using gum. Seems perfect for a relatively easy tui.

Maybe autostart the installing process after 5 secs if the user doesn't input anything like the grub menu or something.

I also had the idea to check if components were installed. Now I'm not sure how to do this since if you can call a programm with bash, that doesn't mean that the programm can be executed with fish.

There surely is a way to do something like fish -c "type rustup" or something.

Is your feature request related to a problem? Please describe.
F.e. when it comes to parsing the input file the errors are to vague to be useful.

Describe the solution you'd like
A: better error messages
B: A check option to only check if the file would be parsed correctly

There are some problems with fonts sometimes. I found that by using nerd fonts and installing all of them, I get rid of them.
These are the steps:

git clone --depth 1 https://github.com/ryanoasis/nerd-fonts.git
cd nerd-fonts
./install.sh

This project is a mirror and has moved to codeberg.org

You are still welcome to follow and partake in the development of ginst and it's components over there!

• libginst
• ginst
• ginst-tui

Is your feature request related to a problem? Please describe.
I like the TUI as it is currently. Not a whole lot of stuff going on there but it would be nice to be able to just execute all installation and configuration instructions without having to click around.

Describe the solution you'd like
ginst -ci --file progs.json for quick install and configuration of all programs in the file.

Describe alternatives you've considered
/

Additional context
/

A common problem was that if you wanted to use ginst you'd have to have cargo installed. This is the job of ginst tho so instead i will provide binaries for most architectures in the future.

Desirable targets are probably:

• amd64
• x86_64
• arm64
• aarch64

and probably a lot more. Idealy I want to cover almost every architecture if thats possible.

Bug

Script will not install fish on debian.

Expectation

Installs fish via apt normally and finds it with type

Additional context

Output:

git is /usr/bin/git
curl is /usr/bin/curl
make is /usr/bin/make
nvim is /usr/bin/nvim
./fti.sh: line 30: type: fish: not found
fish not installed, installing now...
./fti.sh: line 30: type: rustup: not found
Rust not installed, installing now...
info: downloading installer
info: profile set to 'default'
info: default host triple is x86_64-unknown-linux-gnu
warning: Updating existing toolchain, profile choice will be ignored
info: syncing channel updates for 'stable-x86_64-unknown-linux-gnu'
info: default toolchain set to 'stable-x86_64-unknown-linux-gnu'

  stable-x86_64-unknown-linux-gnu unchanged - rustc 1.64.0 (a55dd71d5 2022-09-19)


Rust is installed now. Great!

To get started you may need to restart your current shell.
This would reload your PATH environment variable to include
Cargo's bin directory ($HOME/.cargo/bin).

To configure your current shell, run:
source "$HOME/.cargo/env"
./fti.sh: line 30: type: fish: not found

OS

Debian 11.5 on WSL

The tests don't run through. Not sure why tho.
It always fails in the from_json at this point:

pub fn from_json(json_parsed: &JsonValue) -> Program {
    let mut prog: Program = Default::default();

    prog.name = json_parsed["name"].clone().to_string();
    prog.installation = instructionset::from_json(json_parsed["installation"].clone());
    prog.configuration = instructionset::from_json(json_parsed["configuration"].clone());
    prog.status = prog.check(); // FAILS RIGHT HERE
    prog.dependencies = collection_from_json(json_parsed["dependencies"].clone());
    
    prog
}

The check looks like this:

    fn check(&self) -> Status {
        /* Performs a check if the program is installed */
        let status = Command::new("command")
                        .arg("-v")
                        .arg(&self.name)
                        .status()
                        .expect("Failed to execute."); // fails to execute

        if status.success() {
            Status::Installed
        } else {
            Status::Missing
        }
    }

which is weird because locally it does work.

Perhaps it's something about command not being in environment in the actions? No idea maybe someone else knows a little more or I'll find out some day.