Merge pull request #60 from AleixMT/release-v0.16.0

Release v0.16.0

Author: Axlfc

.gitattributes

@@ -0,0 +1,2 @@
+*.svg filter=lfs diff=lfs merge=lfs -text
+*.png filter=lfs diff=lfs merge=lfs -text

.githooks/post-checkout

@@ -0,0 +1,3 @@
+#!/bin/sh
+command -v git-lfs >/dev/null 2>&1 || { echo >&2 "\nThis repository is configured for Git LFS but 'git-lfs' was not found on your path. If you no longer wish to use Git LFS, remove this hook by deleting .git/hooks/post-checkout.\n"; exit 2; }
+git lfs post-checkout "$@"

.githooks/post-commit

@@ -0,0 +1,3 @@
+#!/bin/sh
+command -v git-lfs >/dev/null 2>&1 || { echo >&2 "\nThis repository is configured for Git LFS but 'git-lfs' was not found on your path. If you no longer wish to use Git LFS, remove this hook by deleting .git/hooks/post-commit.\n"; exit 2; }
+git lfs post-commit "$@"

.githooks/post-merge

@@ -0,0 +1,3 @@
+#!/bin/sh
+command -v git-lfs >/dev/null 2>&1 || { echo >&2 "\nThis repository is configured for Git LFS but 'git-lfs' was not found on your path. If you no longer wish to use Git LFS, remove this hook by deleting .git/hooks/post-merge.\n"; exit 2; }
+git lfs post-merge "$@"

.githooks/pre-commit

@@ -0,0 +1,13 @@
+#!/bin/sh
+# https://stackoverflow.com/questions/30733415/how-to-determine-if-git-merge-is-in-process
+# We avoid commits only if we are not in merge state.
+if git merge HEAD >/dev/null 2>&1; then
+  branch="$(git rev-parse --abbrev-ref HEAD)"
+  if [ "${branch}" = "master" ]; then
+    echo "Are you an idiot? committing directly to master branch is FORBIDDEN"
+    exit 1
+  elif [ "${branch}" = "develop" ]; then
+    echo "Are you an idiot? committing directly to develop branch is FORBIDDEN"
+    exit 1
+  fi
+fi

.githooks/pre-push

@@ -0,0 +1,3 @@
+#!/bin/sh
+command -v git-lfs >/dev/null 2>&1 || { echo >&2 "\nThis repository is configured for Git LFS but 'git-lfs' was not found on your path. If you no longer wish to use Git LFS, remove this hook by deleting .git/hooks/pre-push.\n"; exit 2; }
+git lfs pre-push "$@"

.github/logo.png

@@ -12,6 +12,9 @@
 
 # Linux swap files
 .swp
+*.swp
+*.swo
+*~
 
 # Linux trash folder which might appear on any partition or disk
 .Trash-*
@@ -65,3 +68,7 @@ nohup.out
 wget-log
 *.ipynb
 
+# Used by customizer in WSL2 to store the user name
+whoami
+
+Linux-Auto-Customizer

.gitignore

@@ -23,4 +23,8 @@ copyq
 precoded
 COMPREPLY
 tsend
-clockmoji
+clockmoji
+Dialup
+Geoscience
+fdupes
+Aleix

.spelling_dictionary.dic

@@ -107,6 +107,41 @@ cd32379  UPDATED: A table of contents have been added to README.md (Axlfc)
 e40bfe3  FIXED: Bug in clonerepository installation type. There was an rm missing for avoiding collisions (AleixMT)
 ```
 
+## Git Large File-System support
+We are using git-lfs to track binary data on our repository like data from images which do not need to be indexed as
+a normal file in git. Instead, we use git-lfs, a utility to upload binary files to git in a more optimized way, so it
+does not conflict with our pull, push, checkout and clone speeds.
+
+First you need to install git-lfs in your computer. You can use the customizer for this matter if you already have it installed:
+```
+sudo apt-get install -y git-lfs
+```
+or
+```
+sudo customizer-install -v -o git
+```
+
+Then, every time you clone the repository, you need to navigate to the project folder and execute:
+```
+git-lfs install
+```
+You will see sentences similar to these:
+```
+Updated git hooks.
+Git LFS initialized.
+```
+
+Now you can work transparently and uploading binary content. The rules for `git-lfs` to distinguish between indexable
+files (source code) and no-indexable files (binary data) are in the `.gitattributes` file in the root of the project.
+You can include rules there to mark as no-indexable file any type of files regarding its name (and extension). For example:
+``` 
+*.svg filter=lfs diff=lfs merge=lfs -text
+*.png filter=lfs diff=lfs merge=lfs -text
+```
+
+Which are two rules that make all the files with `.svg` and `.png` extension trackable by git-lfs. These rules are already
+in the repository. 
+
 ## Semantic versioning
 
 We do use semantic versioning as defined in [here](https://semver.org/). 
@@ -119,64 +154,100 @@ PATCH version when you make backwards compatible bug fixes.
 Additional labels for pre-release and build metadata are available as extensions to the MAJOR.MINOR.PATCH format.
 
 
+## Git hooks
+Commits on develop branch and master branch are forbidden. Merge in develop and master branch hasve to be forcibly with the option --no-ff 
+
 # Business Rules
 These are a set of rules that are used to build the installation of each feature in the customizer environment to 
 maximize the usability and fanciness of each of them and the different capabilities and subsystems available.
 
 ###### Environmental
-- [x] Both behaviors of the script use the file `~/.config/user-dirs.dirs` to set some language-independent environment variables (for example, to get an independent system-language path to the Desktop), so some functions of this script will fail if this file does not exist. The variables declared in this file that are used in the customizer are `XDG_DESKTOP_DIR=/home/username/Desktop`, `XDG_PICTURES_DIR=/home/username/Images`, `XDG_TEMPLATES_DIR=/home/username/Templates`.
-- [x] Customizer must not rely ever on the working directory, that is why relative paths are completely avoided (only allowed in necessary cases in . In the same vein, files must not be downloaded in the working directory, they should be deleted in a controlled location. In most cases, this location is `BIN_FOLDER`.
+- [x] Both behaviors of the script use the file `~/.config/user-dirs.dirs` to set some language-independent environment 
+variables (for example, to get an independent system-language path to the Desktop), so some functions of this script 
+will fail if this file does not exist. The variables declared in this file that are used in the customizer are
+`XDG_DESKTOP_DIR=/home/username/Desktop`, 
+`XDG_PICTURES_DIR=/home/username/Images`, 
+`XDG_TEMPLATES_DIR=/home/username/Templates`.
+- [x] Customizer must not rely ever on the working directory, that is why relative paths are completely avoided 
+(only allowed in necessary cases in . In the same vein, files must not be downloaded in the working directory, they 
+should be deleted in a controlled location. In most cases, this location is `BIN_FOLDER`.
 - [ ] All variables should be declared with the needed scope and its write/read permissions (local-r)
 
 ###### Structural
-- [x] The software that is manually installed is put under `BIN_FOLDER`, which by default points to `~/.bin`. `~/.bin` and is always **present** during the execution of `install.sh`.
-- [x] Shell features are not installed directly into `~/.bashrc`, instead, there is always present during the runtime of `install sh` the file `$BIN_FOLDER/bash_functions/.bash_functions`, which is a file imported by `~/.bashrc`. In `~/.bash_functions`, you can write imports to individual scripts that provide a feature to the shell environment. Usually those scripts are stored under `~/.bin/bash_functions/`, which is a location always present. So the generic way to include new content to `~/.bashrc` is writing a script to `~/.bin/bash_functions` and including it in `~/.bash_functions/`.
-- [ ] Soft links to include a program in the PATH are created under `DIR_IN_PATH` which by default points to `~/.local/bin` a directory that is usually already in the PATH. If not, `install.sh` will add it at the beginning of the installation
-- [ ] Files or folders created as root need to change their permissions and also its group and owner to the `${SUDO_USER}` using `chgrp` and `chown`
-- [ ] console features are not installed directly in bashrc; instead use the structure provided by the customizer using .bash_functions
-- [ ] Code lines length is 120 maximum. Lines with more characters need to be split in many. Some exceptions may apply, for example when defining vars that contain links.
+- [x] The software that is manually installed is put under `BIN_FOLDER`, which by default points to `~/.bin`. `~/.bin` 
+and is always **present** during the execution of `install.sh`.
+- [x] Shell features are not installed directly into `~/.bashrc`, instead, there is always present during the runtime 
+of `install sh` the file `$BIN_FOLDER/bash_functions/.bash_functions`, which is a file imported by `~/.bashrc`. 
+In `~/.bash_functions`, you can write imports to individual scripts that provide a feature to the shell environment. 
+Usually those scripts are stored under `~/.bin/bash_functions/`, which is a location always present. So the generic 
+way to include new content to `~/.bashrc` is writing a script to `~/.bin/bash_functions` and including it in 
+`~/.bash_functions/`.
+- [ ] Soft links to include a program in the PATH are created under `DIR_IN_PATH` which by default points to
+`~/.local/bin` a directory that is usually already in the PATH. If not, `install.sh` will add it at the beginning of 
+the installation
+- [ ] Files or folders created as root need to change their permissions and also its group and owner to the 
+`${SUDO_USER}` using `chgrp` and `chown`
+- [ ] console features are not installed directly in bashrc; instead use the structure provided by the customizer using
+.bash_functions
+- [ ] Code lines length is 120 maximum. Lines with more characters need to be split in many. Some exceptions may apply, 
+for example when defining vars that contain links.
 - [ ] help lines in 80 characters.
-- [ ] The tests used in the conditional ifs must be with [ ] instead of [[ ]] when possible. The last one is a bash exclusive feature that we can not find in other shells.
+- [ ] The tests used in the conditional ifs must be with [ ] instead of [[ ]] when possible. The last one is a bash 
+exclusive feature that we can not find in other shells.
 
-(Everything here is by default)
-~/.customizer/
-  bin/ # decompressed files in directories, venvs and manual downloads of icons or other.
+###### Behavioural
+- [x] Each feature is expected to be executed with certain permissions (root / normal user). So the script will skip a 
+feature that needs to be installed with different permissions from the ones that currently has.
+- [x] No unprotected `cd` commands. `cd` must be avoided and never change the working directory given from the outside, 
+that is why they must be called from the inside of a subshell if present.
+- [x] Relative PATHs are forbidden. We must not rely or modify the working directory of the environment of the script. 
+`cd` can be used safely inside a subshell: `$(cd ${BIN_FOLDER} && echo thing`  
+- [x] no `apt`, the default way to install package in script is `apt-get`
+- [x] Only in special cases use echo directly to print to stdout. In most cases you need to use 
+`output_proxy_executioner`
+- [x] desktop launchers created manually have to be created in the desktop and also in the user launchers folder
+- [x] desktop launchers created manually as root have to be in the desktop and also in the all users launchers folder
+- [ ] All `ln`s are created with the option -f, to avoid collision problems.
+- [ ] wget is always used with the `-O` flag, which is used to change the name of the file and / or select a destination
+for the download.
+- [ ] tar is always used in a subshell, cd'ing into an empty directory before the tar, so the working directory of the 
+script is never filled with temporary files.
+
+###### Syntactical
+- [ ] All variables must be expanded by using `${VAR_NAME}` (include the brackets) except for the special ones, like
+`$#`, `$@`, `$!`, `$?`, etc.
+- [ ] There is one blankline between functions in the same block. There is two blanklines between blocks.
+- [ ] using ~ or $HOME instead of HOME_FOLDER
+- [ ] All variables must be protected by using "" to avoid resplitting because of spaces, despite, customizer is not 
+emphasized to work with spaces in its variables. Spaces are *evil* in some paths are not considered.
+- [ ] Indent is always 2 spaces and never TAB.
+- [ ] Categories in each desktop launcher: Name, GenericName, Type, Comment, Version, StartupWMClass, Icon, Exec, 
+Terminal, Categories=IDE;Programming;, StartupNotify, MimeType=x-scheme-handler/tg;, Encoding=UTF-8
+
+# Installation folder structure
+The folder used to install customizer functionalities has the following structure by default:
+```bash
+~/.customizer/  # Installation folder, where ~ is the HOME folder of the user invoking sudo
+  bin/  # Contains a directory for each feature that has to keep a download, create a virtual env, decompress a file, etc.
     studio/
     clion/
     ...
-  cache/ # download will download here and move or copy the download to it's destination depending on the flag
-    clion_downloading
+  temp/  # Downloads will happen here but will be moved afterwards to the destiny location; thus, we will only find failed downloads here
+    clion_downloading.1  # Failed download. It can be safely deleted
+  cache/  # All downloads will be moved here before moving them to its final destination. If a required file to download is already here, it will use the one already in the cache and will ommit the download
+    clion_downloading  # cached file
     mendeley_downloading
     studio_downloading
     ...
-  data/
+  data/  # Contains the files that are used as a database of the used keybindings, active functions, active favorite launchers in the dash... 
     favorites.txt
     keybinds.txt
     bash_functions.sh
     bash_initializations.sh
-  functions/
+  functions/  # Contains the bash files that can be included in the bash environment by using the file data/bash_functions.sh
     a.sh
     b.sh
     ...
-  initializations/
+  initializations/  # Contains the bash files that can be included at the beginning of the session by using the file data/bash_initializations.sh 
     keybinds.sh
-
-###### Behavioural
-- [x] Each feature is expected to be executed with certain permissions (root / normal user). So the script will skip a feature that needs to be installed with different permissions from the ones that currently has.
-- [x] No unprotected `cd` commands. `cd` must be avoided and never change the working directory given from the outside, that is why they must be called from the inside of a subshell if present.
-- [x] Relative PATHs are forbidden. We must not rely or modify the working directory of the environment of the script. `cd` can be used safely inside a subshell: `$(cd ${BIN_FOLDER} && echo thing`  
-- [x] no `apt`, the default way to install package in script is `apt-get`
-- [x] Only in special cases use echo directly to print to stdout. In most cases you need to use `output_proxy_executioner`
-- [x] desktop launchers created manually have to be created in the desktop and also in the user launchers folder
-- [x] desktop launchers created manually as root have to be in the desktop and also in the all users launchers folder
-- [ ] All `ln`s are created with the option -f, to avoid collision problems.
-- [ ] wget is always used with the `-O` flag, which is used to change the name of the file and / or select a destination for the download.
-- [ ] tar is always used in a subshell, cd'ing into an empty directory before the tar, so the working directory of the script is never filled with temporary files.
-
-###### Syntactical
-- [ ] All variables must be expanded by using `${VAR_NAME}` (include the brackets) except for the special ones, like `$#`, `$@`, `$!`, `$?`, etc.
-- [ ] There is one blankline between functions in the same block. There is two blanklines between blocks.
-- [ ] using ~ or $HOME instead of HOME_FOLDER
-- [ ] All variables must be protected by using "" to avoid resplitting because of spaces, despite, customizer is not emphasized to work with spaces in its variables. Spaces are *evil* in some paths are not considered.
-- [ ] Indent is always 2 spaces and never TAB.
-- [ ] Categories in each desktop launcher: Name, GenericName, Type, Comment, Version, StartupWMClass, Icon, Exec, Terminal, Categories=IDE;Programming;, StartupNotify, MimeType=x-scheme-handler/tg;, Encoding=UTF-8
+```