separate each installable element into it's own modular file

[linuxcaffe]

so that everything needed to install/ test/ uninstall each element (task, taskd, at the moment) is self contained and exists in its own file, with an agreed-upon file name convention and essential ingredients. These files don't have to contain executable code, per-se, but must contain a list of each action needed at each step. This removes the task and taskd specific actions from main.sh (tw-install.sh?) and moves them to ~/.task/install/task.install and ~/.task/install/taskd.install. This abstraction becomes the model for any installable element.

[linuxcaffe]

each "element-name.install" file must contain all the info needed, and can be user-modified to suit individual needs. task.install might look something like;

# this is an install file used by Taskwarrior-installation
# https://github.com/HiveMinds-EU/Taskwarrior-installation
# to install, test and uninstall taskwarrior 
# https://taskwarrior.org
# 
name=task
source=dpkg
location=~/.task/
dependencies=g++, libgnutls28-dev, uuid-dev, cmake, gnutls-bin
install=apt install taskwarrior
version=task version
uninstall=apt remove taskwarrior
test=task add test task installation ||task test
etc.

[a-t-0]

Thank you, I think that's a significant improvement on the file structure. I would like to ask 7-3=4 questions.

Folder-structure

In my mind I would like to distinguish between install scripts of (taskwarrior, taskserver and timewarrior) and (hook scripts), because I thought making that difference structurally visible makes the repository less overwhelming for new users. So I thought of:

• Option A:
  • making a separate directory src/core-components/ for the installation of direct components (e.g. taskwarrior, taskserver, timewarrior),
  • making a separate directory src/hook-scripts/ for the installation of hook scripts
  • Making a separate directory src/config-scripts/ for configuration scripts
  • (and perhaps a third category src/other for things that are neither).
• Option B:
  • having the direct components of the Taskwarrior be directly in the src/ folder
  • making a separate directory src/hook-scripts/ for the installation of hook scripts
  • Making a separate directory src/config-scripts/ for configuration scripts
  • (and perhaps a third category src/other for things that are neither).
• Option C: something else, feel free to suggest.

  Folder Structure Question(s):

  My personal preference goes to option A due to symmetry, yet option B might more clearly indicate some form of hierarchy.

1. Question: (ignoring the folder names) Which structural option has your preference? (C can be filled in to your preference)
2. Question: Would you suggest different folder names in the proposed structure option? (This may seem a bit nitpicky, yet I think it's better to give this a lot of thought in advance than to have to change a lot of code at some later stage).

Filename

I think the naming is more compact than install_something.sh, yet for me, it would be/may have been slightly confusing/deterring to see a .install extension, instead of a .sh extension.

I do see how it may be more appropriate if you want to also allow for non-executable install files. Also, based on public data it seems you have more experience in this than I do, so if you indicate this is wise, I will adhere. For correct decision-making procedure, could you perhaps motivate this decision, (even if it may be slightly subjective)?

Filename Questions:

Your example starts with # this is an install file used by Taskwarrior-installation. Something I will have to research myself later this weekend (feel free to ingore these 3 questions):

3. Question: Can I still add the bash shebang on top of an something.install file such that it can be executed if it contains such code?
4. Question: Do the BATS testing system allow for testing on something.install instead of install_something.sh files?
5. Question: Can one make a something.install file executable (with chmod +x something.install)?

Location of hardcoded data

In principle, I was taught that it is better to have your hardcoded variables in a single place such that if you update/change a hardcoded variable, that you only have to change it in one location. Making each install script an independent module seems to go against this principle. However, given (one of) the purpose(s) of this repository, to make it easy for developers to add their hook-script into the auto-installer, it does make it more simple if the scripts are (more) self-contained. Additionally, I can imagine some devs desires on certain overlapping properties/settings in the install/hardcoded may not match, and giving the devs the/some freedom to customise this may reduce some unneeded conflict.

I agree with the proposed structure, but I feel like I have not been able to accurately capture its advantages. So it seems a bit of a subjective decision to me. (No questions, this is just to make the design logic explicit, feel free to elaborate.)

Non-executable something.install files

You mentioned potential non-executable install files, and in the example you gave, you included install=apt install taskwarrior. It gives me the feeling you have (a) different perspective/usecase in mind for these .install files. One such case I could imagine is configuration .install files that are somehow passively read from another script, yet that seems to be conflicting with the independent module idea.

Non-executable something.install files question(s)

6. Question: To test if I may be missing something, could you perhaps briefly elaborate on the (possibly) non-executable .install files?

Independence .install files

I have been taught to minimise code duplicates. This seems in conflict with fully independent .install files, as they would not rely on a helper.sh script with some often used functions.

Independence .install files questions

7. Question: Would you still be in favour of having such a helper.sh script? (At some cost of somewhat reduced independence of these something.install scripts).

[linuxcaffe]

Well I guess I was trying to imagine the simplest approach; all of the "heavy lifting" done by tw-install.sh, using 1 config file for user variables and preferences (tw-install.rc) and a config file for each installable element (task.install, tasksh.install, vit.install, etc). The config files should be user-editable, and should not have to be executable. The reason I think all of this should be contained under the ~/.task/ folder, is so that folder can be backed up to a single .zip file, and all tw-install executables and configs get backed up with all the other taskwarrior goodies.