Add pyproject.toml, poetry.lock, and Makefile for better project setup

[jurassic-squid]

This pull request introduces three new files: pyproject.toml, poetry.lock, and Makefile. These files will streamline the setup process for contributors and ensure consistency across different environments.

The pyproject.toml file is a configuration file for Poetry, which is used to manage project dependencies. It specifies the project's dependencies and other metadata. The poetry.lock file is generated by Poetry and ensures that everyone uses the same versions of dependencies.

The Makefile contains several commands that automate common tasks:

make install: Installs the project's dependencies. make update: Updates the project's dependencies, i.e. retrieves latest versions. make fmt: Formats the code using autoflake, isort, and black. make lint: Checks the code for errors using mypy, flake8, and bandit. make test: Runs the tests.

To set up your environment as a contributor, you'll need to have Poetry installed. Then, you can run make install to install the project's dependencies. You can use the other make commands to format, lint, and test your code.

Please let me know if you have any questions or feedback.

[jurassic-squid]

I can switch the dependencies if you'd rather go with Ruff for formatting and linting @mwermelinger? I haven't used it but it looks really good.

[mwermelinger]

Thanks for this. I've not used Ruff, autoflake or bandit myself, so let's go with the tools you chose for the moment. We can always update to Ruff later, after we experiment with it and if it turns out to be better. I've assigned @densnow as reviewer as I'm on leave this week.

[densnow]

Tested on Linux and everything seems to be working as expected now. This is a nice contribution to the project and gets the ball rolling for a lot of other things. Many thanks @jurassic-squid

In the future it would be nice to add some documentation about the new workflow for contributors what do you think @mwermelinger. For now though, this is ready to be merged.

[mwermelinger]

Thanks both. @densnow please go ahead w/ the squash and merge.

[densnow]

@mwermelinger I don't seem to have write permissions for this repo, only the M269 installer, so cannot squash and merge at present.

[jurassic-squid]

I've done a first draft of an updated contribution.md file @mwermelinger @densnow . I tried to make it as accessible as possible to other students that may want to contribute or just learn a bit about git and GitHub. Let me know what you think. Of course I am open to making changes to any of the content or formatting, etc. It may be a good idea to post it in the M269 forum too to get some feedback, if you do indeed hope to get more contributions from students. Version control and environment set up can be a bit of a blocker to this, so I think we should aim to make it as painless as possible.

[densnow]

@jurassic-squid RE updated contribution.md: In general, I like the accessible approach you have taken, and certainly agree about environment and version control being blockers. Please take the points below as things which require further discussion and by no means as absolute truths.

• The desktop app is another option for interfacing with GH which can abstract away some of the interaction with Git in the CLI. This could be worth mentioning as some students might be put off by a lot of terminal commands.
• Is a pure Windows environment as opposed to WSL an option for contributors? It comes down to the pytype dependency again and how it is not supported on Windows. Things like running tests with -m option would not work and poetry might complain if pytype was absent
• If the point above is True, it follows that a WSL installation will have to be recommended for Windows users with links to documentation.
• It could be worth Mentioning to M269 students specifically that they can ask any questions re contributing on the VLE Tech forum as well as GH forums.
• Sometimes other projects mention that contributions do not necessarily have to be in the form of code. For example, correcting typos in documentation or updating rotten links etc. Is this something we want to mention?

Any thoughts?

[jurassic-squid]

@densnow Thanks for the feedback. I agree with all your points. I forgot that pytype doesn't work on Windows! I should probably add the step: 'run tests' before staging and commiting changes too. Always a good idea.

Could you point me towards the forums you mentioned? I'm not sure exactly which ones you mean.

I'll wait to hear back from Michel and then make changes.

[densnow]

@jurassic-squid Yes good points about the tests, that reminds me you should probably mention the formatting and linting as part of the workflow as well.

RE Forums: Sorry that was not very clear, I just meant the Technical forum on the M269 module website. The forums on GitHub (GH) are the ones accessed by clicking on the discussions tab at top of the page in this project (next to pull requests on my machine)

Incase you see the term used elsewhere: VLE = Virtual Learning environment = the module website. They have a lot of acronyms at the OU :smile:

[jurassic-squid]

I think I have addressed all the issues in contributing.md. I have ticked Allow edits by maintainters, so if there are any further changes you'd like to make, you can commit to the branch. That might be easier. I won't be offended if you want to change/delete any bits!