Suggestion: Organize package manager wrappers in their own files

[gtsop]

Looking at the code I felt the urge to split the wrapper implementations in separate files like so:

- piu
- piu.bats
- wrappers/
     - apt.sh
     - apt.bats
     - brew.sh
     - brew.bats
     - pacman.sh
     - pacman.bats

It doesn't have to be done all at once. They can be individually split over time. Will most likely allow us to work on various features in parallel without conflicts, since now everyone should be editing the same file to do anything really.

Edit: Just realized that would break the installation process since right now one is prompted to download and copy the piu file into the bin directory. So the options are:

1. Entierly dismiss the possibility of having more than one file in the source code
2. Change the installation to require a clone (or download of a release bundle) and create a symlink to the bin directory
3. Have a build CI that would concatenate everything together on every release and publish a single file with all the code. Still the instructions would change to downloading the release instead of a raw source file but the rest of the instalation remains the same (user would have to copy the piu file to their bin directory instead of linking it)

So i guess the scope of this is a bit more than I initially thought. I'd be interested in hearing what you think about all that.

[beyondmeh]

I like the idea for code maintainability. It definitely isn't lost on me that piu could become quite a beast down the road to maintain. However, I think keeping the install process simple and having a single executable is essential. Along those lines, I would like to keep contributing as simple as possible to encourage others.

That said, using CI would solve the problem. I would like to keep it simple, say limiting itself to concatenating the files together based on placeholders in the main script, just so it's easy for new contributors to understand.

A third solution isn't as elegant, but it might be a stepping stone to CI. Using src/ and dist/ folders and using something akin to a Makefile. Building the script would be up to the committers, however this later could be part of the CI process. In this way, only the URL location to download piu would change.

Let me think about this for a little bit and see what would make the most sense. I'm definitely interested in splitting piu's logic into easy to manage components.

[scottdotau]

Might be worthwhile to use GitHub releases for the executable (via CI concatenation) , and you can split the source up within the code.

That way nothing really changes from an end user perspective (just install latest release), you don't need to store a compiled version, and code base can be a bit more structured / maintainable

[beyondmeh]

@scottgearyau I like that idea for it's simplicity; not having to maintain a separate all-in-one script for the end user. I think I'll go that route.

Also, I wanted to state I haven't been on Github that much due to coworker passing from COVID. Things are very up in the air right now at my workplace as well as the emotional toll of loosing a close friend. As soon as things settle piu's development will continue. I am not abandoning it by any means.

[gtsop]

No worries mate, do whatever it takes so you are well again :)

[scottdotau]

That's horrible, sorry to hear. Take it easy mate! I've forked and begun writing a simple build script (via Makefile) that can be worked on over time ☺

Edit: On second thoughts, might just convert to a bash script... doesn't make sense to add another dependency (no matter how common)?

[zen0bit]

something like pmm from bedrock linux does..

Are you saw it? I like it, maybe take a look for inspiration...

[beyondmeh]

Bedrock is pretty awesome, but this was the first time I looked behind the curtain, so to speak with pmm. I really like the idea.

Going forward I want some feedback on a monolithic vs. modular design for the future:

Assume we've already separated out each package manager's logic (apt, dnf, etc) into individual files:

Options:

• A. Have all of the logic built-in
  • GitHub releases / CI would auto concat the separate files into one bash script
  • pro/cons: An all-in-one script, but development gets a little more complicated for the first time GitHub contributor
  • We don't necessarily need to do CI in which case the cons are a moot point
• B. Pull logic from individual config files like pmm
  • those would still be distributed with piu, but there would need to be "installer logic" for lack of a better term to put them somewhere like ~/.config or /opt
  • pro/cons: Easier to develop, but we'd have to maintain an installer script
• C. Do the above, but dynamically download it on first run (instead of distributing it with the download)
  • Note that the auto-detection logic is already in piu, there wouldn't need to be additional logic besides downloading the given config file
  • pro/cons: Development on our end is easier and piu is still easy to install for the user, but piu would be downloading config files from online
  • is that even a problem?

So I'd like to hear from everyone what direction they think we should take this.