Setting up the project

[MichaHllx]

Creation of a batch script (.bat) that runs under Windows using the command prompt (not for PowerShell, possible improvement).
Creation of a bash script (.sh) that runs on Linux and macOS. This script works with the zsh shell and the bash shell.

Advantages:

• The user has virtually nothing to do thanks to the script.
• The readme is easier to understand and more compact.
• If an error is reported, it's easier to understand what the problem is because all users will do exactly the same thing (i.e. run the script). So it's easier to understand where the problem is coming from.
• The dependencies are centralised in one place.

Possible improvements to my contribution:

• Develop a script that works with the new Windows PowerShell.
• Set up a tutorial to install the correct version of python if necessary (for beginners).
• Find a way to solve the problem of the single dependency that requires a very restrictive version of python.

In conclusion, I think and hope that this contribution will solve some of the problems that users had. In any case, I think it will help users who are less at ease with the domain. And I also hope that it will make maintenance work easier afterwards for the developer.

[nickpadd]

I believe having the user independently download the .sh file to clone the repository and install dependencies might introduce some confusion. Here’s why:

1. For users without Git installed: The script would fail, as cloning relies on Git being present.
2. For experienced users: It’s more intuitive to clone the repository themselves and then run the script from within the project directory. Running the script as is would result in the repository being cloned twice.

Suggested Changes

1. Simplify the Workflow:

   • Assume users will first clone the repository manually (we should provide clear instructions for it). Then, the script can focus solely on setting up the environment and dependencies within the cloned project directory.

2. Consistent Naming:

   • To maintain consistency, I suggest adopting the snake_case naming convention for directories and files.
   • Scripts intended for user interaction could include the run keyword, making their purpose clearer (e.g., run_setup.sh).

[nickpadd]

Suggested change

	# Clone the repository in the current directory
	git clone https://github.com/nickpadd/EuropeanFootballLeaguePredictor
	# Browse the project directory
	cd EuropeanFootballLeaguePredictor || exit

[nickpadd]

Suggested change

	$PYTHON -m venv EFLPvenv
	$PYTHON -m venv eflp_venv

[nickpadd]

Suggested change

	source EFLPvenv/bin/activate
	source eflp_venv/bin/activate

[nickpadd]

Suggested change

	EFLPvenv/bin/pip install -r requirements.txt
	eflp_venv/bin/pip install -r requirements.txt

[nickpadd]

If the .sh and .bat scripts are modified to exclude the cloning procedure, these lines should explicitly specify the steps for cloning the repository.

[nickpadd]

Suggested change

	bash PROJECT-SETUP.sh
	bash run_project_setup.sh

[nickpadd]

Suggested change

	PROJECT-SETUP.bat
	run_project_setup.bat

[nickpadd]

Suggested change

	source EFLPvenv/bin/activate
	source eflp_venv/bin/activate

[nickpadd]

Suggested change

	EFLPvenv\Scripts\activate
	eflp_venv\Scripts\activate

[nickpadd]

I suggest the same changes as in the .sh script, as well as changing the name to run_project_setup.bat for consistency!

[nickpadd]

Great work! I have left a few comments, primarily regarding naming convention changes and workflow improvements. Specifically:

1. Naming Conventions: I suggest using snake_case for directory and script names to maintain consistency and follow common conventions. Additionally, including the run keyword in user-facing scripts (e.g., run_setup.sh) makes their purpose clearer.

2. Cloning Workflow: If the .sh and .bat scripts are modified to exclude repository cloning, ensure the documentation or script comments provide clear instructions for users to manually clone the repository before running the setup scripts. This avoids confusion and unnecessary duplication.

Once these changes are addressed, I’ll be happy to approve and merge.