From 7cbc5dc1cfce844a9620ba902a7d576079e58c06 Mon Sep 17 00:00:00 2001
From: Steele If you don't have Git on your computer already, install it. You can additionally install a Git GUI such as GitKraken, or the GitHub CLI. To learn more about Git, you can look into our guides, as well as this cheatsheet, Learn Git Branching, and otherwise any guide you can find on the internet. Once you got the basic idea though, the best way to learn Git is to use it. Creating a copy of a repository under your own account is called a fork. This is where all your changes and commits will be pushed to, and from where your pull requests will originate from.
+Alternatively you can also directly combine them into a single prefix like the following: `\u001b[1;40;32m` and you can also use multiple values. Something like `\u001b[1;40;4;32m` would underline the text, make it bold, make it green and have a dark blue background.
+
+Raw message:
+\`\`\`ansi
+\u001b[0;40m\u001b[1;32mThat's some cool formatted text right?
+or
+\u001b[1;40;32mThat's some cool formatted text right?
+\`\`\`
+
+Result:
+
+
+The way the colors look like on Discord is shown in the image below ^^
+
+Note: If the change as not been brought to you yet, or other users, then you can use other code blocks in the meantime to get colored text. See this gist:
Result:

-The way the colors look like on Discord is shown in the image below ^^
+The way the colors look like on Discord is shown in the image below:
+
Note: If the change as not been brought to you yet, or other users, then you can use other code blocks in the meantime to get colored text. See this gist:
-[Style Guide](./style-guide/) - Information regarding the code styles you should follow when working on our projects.
-[Review Guide](../code-reviews-primer/) - A guide to get you started on doing code reviews.
-
## Contributors Community
We are very happy to have many members in our community that contribute to [our open source projects](https://github.com/python-discord/).
Whether it's writing code, reviewing pull requests, or contributing graphics for our events, it’s great to see so many people being motivated to help out.
@@ -114,3 +106,48 @@ As it’s difficult to precisely quantify contributions, we’ve come up with th
- The member has a positive influence in our contributors subcommunity.
The role will be assigned at the discretion of the Admin Team in consultation with the Core Developers Team.
+
+
+# How do I start contributing?
+ Completing these steps will have you ready to make your first contribution. If you've already been using Git or GitHub feel free to skip those steps, but please make sure to read about the PyDis contributing process and ettiquette. If you are here looking for the answer to a specific question, check out the sub-articles in the top right of the page to see a list of our guides.
+
+
+
+### Fork the repo
+ GitHub is a website based on the Git version control system that stores project files in the cloud. The people working on the project can use GitHub as a central place for sending their changes, getting their teammates' changes, and communicating with each other. Forking the repository that you want to work on will create a copy under your own GitHub account. You'll make your changes to this copy, then later we can bring them back to the PyDis repository.
+
+ [Check out our guide on forking a GitHub repo](./forking-repository/)
+
+### Clone the repo
+ Now that you have your own fork you could make changes to it directly on GitHub, but that's not a convenient way to write code. Instead you can use Git to clone the repo to your local machine, commit changes to it there, then push those changes to GitHub.
+
+ [Check out our guide on forking a GitHub repo](./forking-repository/)
+
+### Set up the project
+ You have the source code on your local computer, but how do you actually run it?
+
+ [Sir Lancebot](./sir-lancebot/)
+
+ [Python Bot](./bot/)
+
+ [Site](./site/)
+
+### Ettiquette
+ [Guidelines](./contributing-guidelines/)
+### Read the style guide
+ [Style Guide](./style-guide/)
+
+### Open a pull request
+
+### The review process
+ [Review Guide](../code-reviews-primer/)
+### Create an issue
+
+
+### Learn the basics of Git
+ Git is a *Version Control System*, software for carefully tracking changes to the files in a project. Git allows the same project to be worked on by people in different places. You can make changes to your local code and then distribute those changes to the other people working on the project.
+
+ [Check out these resources to get started using Git](./working-with-git/)
+
+
+If you don't understand anything or need clarification, feel free to ask any staff member with the **@PyDis Core Developers** role in the server. We're always happy to help!
--
cgit v1.2.3
From 92b1f701b3d1b159b3353db954ce06fe631e56bc Mon Sep 17 00:00:00 2001
From: Cam Caswell
-
-You will need to create a fork of [the project](https://github.com/python-discord/bot), and clone the fork.
-Once this is done, you will have completed the first step towards having a running version of the bot.
-
-#### Working on the Repository Directly
-If you are a member of the organisation (a member of [this list](https://github.com/orgs/python-discord/people), or in our particular case, server staff), you can clone the project repository without creating a fork, and work on a feature branch instead.
-
---
### Set Up a Test Server
diff --git a/pydis_site/apps/content/resources/guides/pydis-guides/contributing/sir-lancebot.md b/pydis_site/apps/content/resources/guides/pydis-guides/contributing/sir-lancebot.md
index e3cd8f0c..6e5a9199 100644
--- a/pydis_site/apps/content/resources/guides/pydis-guides/contributing/sir-lancebot.md
+++ b/pydis_site/apps/content/resources/guides/pydis-guides/contributing/sir-lancebot.md
@@ -41,16 +41,6 @@ The requirements for Docker are:
* This is only a required step for linux. Docker comes bundled with docker-compose on Mac OS and Windows.
---
-
-# Fork the Project
-You will need your own remote (online) copy of the project repository, known as a *fork*.
-
-- [**Learn how to create a fork of the repository here.**](../forking-repository)
-
-You will do all your work in the fork rather than directly in the main repository.
-
----
-
# Development Environment
1. Once you have your fork, you will need to [**clone the repository to your computer**](../cloning-repository).
2. After cloning, proceed to [**install the project's dependencies**](../installing-project-dependencies). (This is not required if using Docker)
@@ -121,13 +111,4 @@ After installing project dependencies use the poetry command `poetry run task st
$ poetry run task start
```
----
-
-# Working with Git
-Now that you have everything setup, it is finally time to make changes to the bot! If you have not yet [read the contributing guidelines](https://github.com/python-discord/sir-lancebot/blob/main/CONTRIBUTING.md), now is a good time. Contributions that do not adhere to the guidelines may be rejected.
-
-Notably, version control of our projects is done using Git and Github. It can be intimidating at first, so feel free to ask for any help in the server.
-
-[**Click here to see the basic Git workflow when contributing to one of our projects.**](../working-with-git/)
-
Have fun!
diff --git a/pydis_site/apps/content/resources/guides/pydis-guides/contributing/site.md b/pydis_site/apps/content/resources/guides/pydis-guides/contributing/site.md
index f2c3bd95..7eda027a 100644
--- a/pydis_site/apps/content/resources/guides/pydis-guides/contributing/site.md
+++ b/pydis_site/apps/content/resources/guides/pydis-guides/contributing/site.md
@@ -26,18 +26,6 @@ Without Docker:
- [PostgreSQL](https://www.postgresql.org/download/)
- Note that if you wish, the webserver can run on the host and still use Docker for PostgreSQL.
----
-# Fork the project
-
-You will need access to a copy of the git repository of your own that will allow you to edit the code and push your commits to.
-Creating a copy of a repository under your own account is called a _fork_.
-
-- [Learn how to create a fork of the repository here.](../forking-repository/)
-
-This is where all your changes and commits will be pushed to, and from where your PRs will originate from.
-
-For any Core Developers, since you have write permissions already to the original repository, you can just create a feature branch to push your commits to instead.
-
---
# Development environment
diff --git a/pydis_site/apps/content/resources/guides/pydis-guides/contributing/working-with-git.md b/pydis_site/apps/content/resources/guides/pydis-guides/contributing/working-with-git.md
index 26c89b56..59c57859 100644
--- a/pydis_site/apps/content/resources/guides/pydis-guides/contributing/working-with-git.md
+++ b/pydis_site/apps/content/resources/guides/pydis-guides/contributing/working-with-git.md
@@ -19,5 +19,7 @@ Below are links to regular workflows for working with Git using PyCharm or the C
**Resources to learn Git**
* [The Git Book](https://git-scm.com/book)
-* [Corey Schafer's Youtube Tutorials](https://www.youtube.com/watch?v=HVsySz-h9r4&list=PL-osiE80TeTuRUfjRe54Eea17-YfnOOAx)
-* [GitHub Git Resources Portal](https://try.github.io/)
+* [Corey Schafer's YouTube tutorials](https://www.youtube.com/watch?v=HVsySz-h9r4&list=PL-osiE80TeTuRUfjRe54Eea17-YfnOOAx)
+* [GitHub Git resources portal](https://try.github.io/)
+* [Git cheatsheet](https://education.github.com/git-cheat-sheet-education.pdf)
+* [Learn Git branching](https://learngitbranching.js.org)
--
cgit v1.2.3
From 36b43f94cb1f8c622914048696efec8ccdeb608f Mon Sep 17 00:00:00 2001
From: Cam Caswell
+
+Failing to comply with our guidelines may lead to a rejection of the contribution.
+If you have questions about any of the rules, feel free to ask us in the `#dev-contrib` channel in our [Discord server](https://discord.gg/python).
+{: .notification .is-warning }
diff --git a/pydis_site/apps/content/resources/guides/pydis-guides/contributing/contributing-guidelines/commit-messages.md b/pydis_site/apps/content/resources/guides/pydis-guides/contributing/contributing-guidelines/commit-messages.md
new file mode 100644
index 00000000..ba476b65
--- /dev/null
+++ b/pydis_site/apps/content/resources/guides/pydis-guides/contributing/contributing-guidelines/commit-messages.md
@@ -0,0 +1,15 @@
+---
+title: Writing Good Commit Messages
+description: Information about logging in our projects.
+---
+
+A well-structured git log is key to a project's maintainability; it provides insight into when and *why* things were done for future maintainers of the project.
+
+Commits should be as narrow in scope as possible.
+Commits that span hundreds of lines across multiple unrelated functions and/or files are very hard for maintainers to follow.
+After about a week they'll probably be hard for you to follow, too.
+
+Please also avoid making minor commits for fixing typos or linting errors.
+[Don’t forget to lint before you push!](https://soundcloud.com/lemonsaurusrex/lint-before-you-push)
+
+A more in-depth guide to writing great commit messages can be found in Chris Beam's [How to Write a Git Commit Message](https://chris.beams.io/posts/git-commit/).
diff --git a/pydis_site/apps/content/resources/guides/pydis-guides/contributing/contributing-guidelines/supplemental-information.md b/pydis_site/apps/content/resources/guides/pydis-guides/contributing/contributing-guidelines/supplemental-information.md
deleted file mode 100644
index e64e4fc6..00000000
--- a/pydis_site/apps/content/resources/guides/pydis-guides/contributing/contributing-guidelines/supplemental-information.md
+++ /dev/null
@@ -1,99 +0,0 @@
----
-title: Supplemental Information
-description: Additional information related to our contributing guidelines.
----
-
-This page contains additional information concerning a specific part of our development pipeline.
-
-## Writing Good Commit Messages
-
-A well-structured git log is key to a project's maintainability; it provides insight into when and *why* things were done for future maintainers of the project.
-
-Commits should be as narrow in scope as possible.
-Commits that span hundreds of lines across multiple unrelated functions and/or files are very hard for maintainers to follow.
-After about a week they'll probably be hard for you to follow, too.
-
-Please also avoid making minor commits for fixing typos or linting errors.
-*[Don’t forget to lint before you push!](https://soundcloud.com/lemonsaurusrex/lint-before-you-push)*
-
-A more in-depth guide to writing great commit messages can be found in Chris Beam's *[How to Write a Git Commit Message](https://chris.beams.io/posts/git-commit/).*
-
-## Code Style
-
-All of our projects have a certain project-wide style that contributions should attempt to maintain consistency with.
-During PR review, it's not unusual for style adjustments to be requested.
-
-[This page](../../style-guide/) will reference the differences between our projects and what is recommended by [PEP 8.](https://www.python.org/dev/peps/pep-0008/)
-
-## Linting and Pre-commit
-
-On most of our projects, we use `flake8` and `pre-commit` to ensure that the code style is consistent across the code base.
-
-Running `flake8` will warn you about any potential style errors in your contribution.
-You must always check it **before pushing**.
-Your commit will be rejected by the build server if it fails to lint.
-
-**Some style rules are not enforced by flake8. Make sure to read the [style guide](../../style-guide/).**
-
-`pre-commit` is a powerful tool that helps you automatically lint before you commit.
-If the linter complains, the commit is aborted so that you can fix the linting errors before committing again.
-That way, you never commit the problematic code in the first place!
-
-Please refer to the project-specific documentation to see how to setup and run those tools.
-In most cases, you can install pre-commit using `poetry run task precommit`, and lint using `poetry run task lint`.
-
-## Type Hinting
-
-[PEP 484](https://www.python.org/dev/peps/pep-0484/) formally specifies type hints for Python functions, added to the Python Standard Library in version 3.5.
-Type hints are recognized by most modern code editing tools and provide useful insight into both the input and output types of a function, preventing the user from having to go through the codebase to determine these types.
-
-For example:
-
-```python
-import typing
-
-def foo(input_1: int, input_2: typing.Dict[str, str]) -> bool:
- ...
-```
-
-This tells us that `foo` accepts an `int` and a `dict`, with `str` keys and values, and returns a `bool`.
-
-If the project is running Python 3.9 or above, you can use `dict` instead of `typing.Dict`.
-See [PEP 585](https://www.python.org/dev/peps/pep-0585/) for more information.
-
-All function declarations should be type hinted in code contributed to the PyDis organization.
-
-## Logging
-
-Instead of using `print` statements for logging, we use the built-in [`logging`](https://docs.python.org/3/library/logging.html) module.
-Here is an example usage:
-
-```python
-import logging
-
-log = logging.getLogger(__name__) # Get a logger bound to the module name.
-# This line is usually placed under the import statements at the top of the file.
-
-log.trace("This is a trace log.")
-log.warning("BEEP! This is a warning.")
-log.critical("It is about to go down!")
-```
-
-Print statements should be avoided when possible.
-Our projects currently defines logging levels as follows, from lowest to highest severity:
-
-- **TRACE:** These events should be used to provide a *verbose* trace of every step of a complex process. This is essentially the `logging` equivalent of sprinkling `print` statements throughout the code.
-- **Note:** This is a PyDis-implemented logging level. It may not be available on every project.
-- **DEBUG:** These events should add context to what's happening in a development setup to make it easier to follow what's going while workig on a project. This is in the same vein as **TRACE** logging but at a much lower level of verbosity.
-- **INFO:** These events are normal and don't need direct attention but are worth keeping track of in production, like checking which cogs were loaded during a start-up.
-- **WARNING:** These events are out of the ordinary and should be fixed, but can cause a failure.
-- **ERROR:** These events can cause a failure in a specific part of the application and require urgent attention.
-- **CRITICAL:** These events can cause the whole application to fail and require immediate intervention.
-
-Any logging above the **INFO** level will trigger a [Sentry](https://sentry.io) issue and alert the Core Developer team.
-
-## Draft Pull Requests
-
-Github [provides a PR feature](https://github.blog/2019-02-14-introducing-draft-pull-requests/) that allows the PR author to mark it as a Draft when opening it. This provides both a visual and functional indicator that the contents of the PR are in a draft state and not yet ready for formal review.
-
-This feature should be utilized in place of the traditional method of prepending `[WIP]` to the PR title.
diff --git a/pydis_site/apps/content/resources/guides/pydis-guides/contributing/linting.md b/pydis_site/apps/content/resources/guides/pydis-guides/contributing/linting.md
new file mode 100644
index 00000000..48f1cafc
--- /dev/null
+++ b/pydis_site/apps/content/resources/guides/pydis-guides/contributing/linting.md
@@ -0,0 +1,14 @@
+---
+title: Linting
+description: A guide for linting and setting up pre-commit.
+---
+
+Your commit will be rejected by the build server if it fails to lint.
+On most of our projects, we use `flake8` and `pre-commit` to ensure that the code style is consistent across the code base.
+
+`pre-commit` is a powerful tool that helps you automatically lint before you commit.
+If the linter complains, the commit is aborted so that you can fix the linting errors before committing again.
+That way, you never commit the problematic code in the first place!
+
+Please refer to the project-specific documentation to see how to setup and run those tools.
+In most cases, you can install pre-commit using `poetry run task precommit`, and lint using `poetry run task lint`.
diff --git a/pydis_site/apps/content/resources/guides/pydis-guides/contributing/logging.md b/pydis_site/apps/content/resources/guides/pydis-guides/contributing/logging.md
new file mode 100644
index 00000000..1291a7a4
--- /dev/null
+++ b/pydis_site/apps/content/resources/guides/pydis-guides/contributing/logging.md
@@ -0,0 +1,31 @@
+---
+title: Logging
+description: Information about logging in our projects.
+---
+
+Instead of using `print` statements for logging, we use the built-in [`logging`](https://docs.python.org/3/library/logging.html) module.
+Here is an example usage:
+
+```python
+import logging
+
+log = logging.getLogger(__name__) # Get a logger bound to the module name.
+# This line is usually placed under the import statements at the top of the file.
+
+log.trace("This is a trace log.")
+log.warning("BEEP! This is a warning.")
+log.critical("It is about to go down!")
+```
+
+Print statements should be avoided when possible.
+Our projects currently defines logging levels as follows, from lowest to highest severity:
+
+- **TRACE:** These events should be used to provide a *verbose* trace of every step of a complex process. This is essentially the `logging` equivalent of sprinkling `print` statements throughout the code.
+- **Note:** This is a PyDis-implemented logging level. It may not be available on every project.
+- **DEBUG:** These events should add context to what's happening in a development setup to make it easier to follow what's going while workig on a project. This is in the same vein as **TRACE** logging but at a much lower level of verbosity.
+- **INFO:** These events are normal and don't need direct attention but are worth keeping track of in production, like checking which cogs were loaded during a start-up.
+- **WARNING:** These events are out of the ordinary and should be fixed, but can cause a failure.
+- **ERROR:** These events can cause a failure in a specific part of the application and require urgent attention.
+- **CRITICAL:** These events can cause the whole application to fail and require immediate intervention.
+
+Any logging above the **INFO** level will trigger a [Sentry](https://sentry.io) issue and alert the Core Developer team.
diff --git a/pydis_site/apps/content/resources/guides/pydis-guides/contributing/pull-requests.md b/pydis_site/apps/content/resources/guides/pydis-guides/contributing/pull-requests.md
index f7dee491..a9b6385e 100644
--- a/pydis_site/apps/content/resources/guides/pydis-guides/contributing/pull-requests.md
+++ b/pydis_site/apps/content/resources/guides/pydis-guides/contributing/pull-requests.md
@@ -10,7 +10,7 @@ As stated in our [Contributing Guidelines](../contributing-guidelines/), do not
Before opening a pull request you should have:
1. Committed your changes to your local repository
-2. [Linted](../contributing-guidelines/#linting-and-pre-commit) your code
+2. [Linted](../linting/) your code
3. Tested your changes
4. Pushed the branch to your fork of the project on GitHub
diff --git a/pydis_site/apps/content/resources/guides/pydis-guides/contributing/style-guide.md b/pydis_site/apps/content/resources/guides/pydis-guides/contributing/style-guide.md
index f9962990..4dba45c8 100644
--- a/pydis_site/apps/content/resources/guides/pydis-guides/contributing/style-guide.md
+++ b/pydis_site/apps/content/resources/guides/pydis-guides/contributing/style-guide.md
@@ -191,21 +191,17 @@ Present tense defines that the work being done is now, in the present, rather th
**Use:** "Build an information embed."
**Don't use:** "Built an information embed." or "Will build an information embed."
-# Type Annotations
-Functions are required to have type annotations as per the style defined in [PEP 484](https://www.python.org/dev/peps/pep-0484/).
+# Type Hinting
+Functions are required to have type annotations as per the style defined in [PEP 484](https://www.python.org/dev/peps/pep-0484/). Type hints are recognized by most modern code editing tools and provide useful insight into both the input and output types of a function, preventing the user from having to go through the codebase to determine these types.
-A function without annotations might look like:
-```py
-def divide(a, b):
- """Divide the two given arguments."""
- return a / b
-```
-
-With annotations, the arguments and the function are annotated with their respective types:
-```py
-def divide(a: int, b: int) -> float:
- """Divide the two given arguments."""
- return a / b
+A function with type hints looks like:
+```python
+def foo(input_1: int, input_2: dict[str, int]) -> bool:
+ ...
```
+This tells us that `foo` accepts an `int` and a `dict`, with `str` keys and `int` values, and returns a `bool`.
In previous examples, we have purposely omitted annotations to keep focus on the specific points they represent.
+
+> **Note:** if the project is running Python 3.8 or below you have to use `typing.Dict` instead of `dict`, but our three main projects are all >=3.9.
+> See [PEP 585](https://www.python.org/dev/peps/pep-0585/) for more information.
--
cgit v1.2.3
From 79694efe7bb13a9d6791844e7a836b7f4350308d Mon Sep 17 00:00:00 2001
From: Cam Caswell
\u001b[1;40;32mThat's some cool formatted text right?
\`\`\`
-Result:
+Result:
+

The way the colors look like on Discord is shown in the image below:
--
cgit v1.2.3
From 1017676bea05d423d86a29c2ede769a6288a3d4a Mon Sep 17 00:00:00 2001
From: Cam Caswell
websockets
-websockets is a library for building WebSocket servers and clients in Python with a focus on correctness, simplicity, robustness, and performance. - Built on top of asyncio, Python’s standard asynchronous I/O framework, it provides an elegant coroutine-based API. +
FastAPI
+FastAPI is a modern, fast (high-performance), web framework for building APIs with Python 3.6+ based on standard Python type hints.
Flask-SocketIO
-Flask-SocketIO gives Flask applications access to low latency bi-directional communications between the clients and the server. +
Starlette
+Starlette is a lightweight ASGI framework/toolkit, which is ideal for building async web services in Python.
Django Channels
-Channels is a project that takes Django and extends its abilities beyond HTTP - to handle WebSockets, chat protocols, IoT protocols, and more. - It’s built on a Python specification called ASGI. +
websockets
+websockets is a library for building WebSocket servers and clients in Python with a focus on correctness, simplicity, robustness, and performance. + Built on top of asyncio, Python’s standard asynchronous I/O framework, it provides an elegant coroutine-based API.
wsproto
-wsproto is a WebSocket protocol stack written to be as flexible as possible. - To that end it is written in pure Python and performs no I/O of its own. - Instead it relies on the user to provide a bridge between it and whichever I/O mechanism is in use, allowing it to be used in single-threaded, multi-threaded or event-driven code. +
Django Channels
+Channels is a project that takes Django and extends its abilities beyond HTTP - to handle WebSockets, chat protocols, IoT protocols, and more. + It’s built on a Python specification called ASGI.
Starlette
-Starlette is a lightweight ASGI framework/toolkit, which is ideal for building async web services in Python. +
Flask-SocketIO
+Flask-SocketIO gives Flask applications access to low latency bi-directional communications between the clients and the server.
FastAPI
-FastAPI is a modern, fast (high-performance), web framework for building APIs with Python 3.6+ based on standard Python type hints. +
wsproto
+wsproto is a WebSocket protocol stack written to be as flexible as possible. + To that end it is written in pure Python and performs no I/O of its own. + Instead it relies on the user to provide a bridge between it and whichever I/O mechanism is in use, allowing it to be used in single-threaded, multi-threaded or event-driven code.
FastAPI
-FastAPI is a modern, fast (high-performance), web framework for building APIs with Python 3.6+ based on standard Python type hints. +
FastAPI is a modern web framework great for WebSockets based on standard Python type hints which provides great editor support.
websockets
-websockets is a library for building WebSocket servers and clients in Python with a focus on correctness, simplicity, robustness, and performance. - Built on top of asyncio, Python’s standard asynchronous I/O framework, it provides an elegant coroutine-based API. +
websockets is a library for building both WebSocket clients and servers with focus on simplicity and performance.
Django Channels
-Channels is a project that takes Django and extends its abilities beyond HTTP - to handle WebSockets, chat protocols, IoT protocols, and more. - It’s built on a Python specification called ASGI. +
Django Channels adds WebSocket-support to Django - built on ASGI like other web frameworks.
wsproto
-wsproto is a WebSocket protocol stack written to be as flexible as possible. - To that end it is written in pure Python and performs no I/O of its own. - Instead it relies on the user to provide a bridge between it and whichever I/O mechanism is in use, allowing it to be used in single-threaded, multi-threaded or event-driven code. +
wsproto is a pure-Python WebSocket protocol stack written to be as flexible as possible by having the user build the bridge to the I/O.
The Qualifier isn't released yet, but to receive the most up-to-date information and to get notified - when the Qualifier is released you can join the server: discord.gg/python.
- ++ Before being able to join the code jam, you must complete a qualifier which tests your knowledge in Python. + The qualifier can be found on our GitHub + and once completed you should submit your solution using the sign-up form. +
The chosen technology/tech stack for this year is WebSockets.
--
cgit v1.2.3
From 4847f18d50158dcfbe8c9a84b54bcfe25e0b7452 Mon Sep 17 00:00:00 2001
From: Bluenix Every year we hold a community-wide Summer Code Jam. For this event, members of our community are assigned to teams to collaborate and create something amazing using a technology we picked for them. One such technology that was picked for the Summer 2021 Code Jam was text user interfaces (TUIs), where teams could pick from a pre-approved list of frameworks. To help fuel the creative process, we provide a specific theme, like Think Inside the Box or Early Internet. At the end of the Code Jam, the projects are judged by Python Discord server staff members and guest judges from the larger Python community. The judges will consider creativity, code quality, teamwork, and adherence to the theme.
--
cgit v1.2.3
From 924489925a0eafecca67c041377f14a9ba632844 Mon Sep 17 00:00:00 2001
From: Bluenix Code Jams
Important Dates
-
Saturday, June 18 - Form to submit theme suggestions opensWednesday, June 29 - The Qualifier is released
ASGI
+ASGI is the specification your favourite frameworks are built on. This is not a framework in of itself, but listed here for completeness.
+ASGI is the specification your favourite frameworks are built on. This is not a framework in of itself, but listed here for completeness.
FastAPI
-FastAPI is a modern web framework great for WebSockets based on standard Python type hints which provides great editor support. -
+FastAPI is a modern web framework great for WebSockets based on standard Python type hints which provides great editor support.
FastAPI
-- cgit v1.2.3 From a6ad20d9fdb133b605a6d2d6f6513f39a8c29356 Mon Sep 17 00:00:00 2001 From: BluenixDjango Channels
- <>Django Channels adds WebSocket-support to Django - built on ASGI like other web frameworks. +Django Channels adds WebSocket-support to Django - built on ASGI like other web frameworks.
Most of the below frameworks implement what is called the ASGI Specification. + This specification documents how the frameworks should interact with ASGI servers and call the frameworks. + You are also allowed to work with the ASGI specification directly without a framework, if your team so chooses to. + Refer to the specification online. +
+ASGI
-ASGI is the specification your favourite frameworks are built on. This is not a framework in of itself, but listed here for completeness.
-Most of the below frameworks implement what is called the ASGI Specification. - This specification documents how the frameworks should interact with ASGI servers and call the frameworks. + This specification documents how the frameworks should interact with ASGI servers. You are also allowed to work with the ASGI specification directly without a framework, if your team so chooses to. Refer to the specification online.
-- cgit v1.2.3 From 9714f81fed18b3b9494b0dee08a859ed6bdbe756 Mon Sep 17 00:00:00 2001 From: mbaruhStarlite
+Starlite is a light and flexible ASGI API framework, using Starlette and Pydantic as foundations. +
+Sanic
+Sanic is an ASGI compliant web framework designed for speed and simplicity. +
+Flask-SocketIO
-Flask-SocketIO gives Flask applications access to low latency bi-directional communications between the clients and the server. -
-wsproto
-wsproto is a pure-Python WebSocket protocol stack written to be as flexible as possible by having the user build the bridge to the I/O. +
Starlite
+Starlite is a light and flexible ASGI API framework, using Starlette and Pydantic as foundations.
Starlite
-Starlite is a light and flexible ASGI API framework, using Starlette and Pydantic as foundations. +
Sanic
+Sanic is an ASGI compliant web framework designed for speed and simplicity.
Sanic
-Sanic is an ASGI compliant web framework designed for speed and simplicity. +
wsproto
+wsproto is a pure-Python WebSocket protocol stack written to be as flexible as possible by having the user build the bridge to the I/O.
AioHTTP
+AioHTTP provides both a client and server WebSocket implementation, while avoiding callback-hell. +
+Your solution must use one of the approved frameworks (a list will be released soon). It is not permitted to circumvent this rule by e.g. using the approved framework as a wrapper for another framework.
Your solution must only communicate through WebSockets. Any communication between the client and server (or any two server workers), must utilize WebSockets.
+ +
+ Exceptions to this rule are made for resources such as databases and files, albeit excluding usage other than for storage.
+ For example, you may use PostgreSQL as a database but not its `NOTIFY` command.
+ Lastly, working with subprocesses (through stdin/stdout or multiprocessing.Pool()
/concurrent.futures.ProcessPoolExecutor()(
) is also exempted from this rule.
+
Your solution should be platform agnostic. For example, if you use filepaths in your submission, use pathlib
to create platform agnostic Path objects instead of hardcoding the paths.
--
cgit v1.2.3
From 2d353e93715205d3365730dcc1ae59f61beba87d Mon Sep 17 00:00:00 2001
From: Bluenix AioHTTP AioHTTP provides both a client and server WebSocket implementation, while avoiding callback-hell.
+ aiohttp aiohttp provides both a client and server WebSocket implementation, while avoiding callback-hell.
Every year we hold a community-wide Summer Code Jam. For this event, members of our community are assigned to teams to collaborate and create something amazing using a technology we picked for them. One such technology that was picked for the Summer 2021 Code Jam was text user interfaces (TUIs), where teams could pick from a pre-approved list of frameworks. To help fuel the creative process, we provide a specific theme, like Think Inside the Box or Early Internet. At the end of the Code Jam, the projects are judged by Python Discord server staff members and guest judges from the larger Python community. The judges will consider creativity, code quality, teamwork, and adherence to the theme. If you want to read more about Code Jams, visit our Code Jam info page or watch this video showcasing the best projects created during the Winter Code Jam 2020: Ancient Technology:
If you've been around the server for a while, or you just happened to join at the right time,
you may have heard of something known as a Code Jam.
--
cgit v1.2.3
From da38a0cf766e8e9f77d93b8cbda958306b7b980b Mon Sep 17 00:00:00 2001
From: Bluenix
Exceptions to this rule are made for resources such as databases and files, albeit excluding usage other than for storage.
For example, you may use PostgreSQL as a database but not its `NOTIFY` command.
- Lastly, working with subprocesses (through stdin/stdout or Your solution should be platform agnostic. For example, if you use filepaths in your submission, use Your solution must only communicate through WebSockets. Any communication between the client and server (or any two server workers), must utilize WebSockets.
- Exceptions to this rule are made for resources such as databases and files, albeit excluding usage other than for storage.
+ An exception to this rule is that communication with databases and files is allowed for accessing resources or for storage purposes.
For example, you may use PostgreSQL as a database but not its `NOTIFY` command.
- Lastly, working with subprocesses (through stdin/stdout or Your solution should be platform agnostic. For example, if you use filepaths in your submission, use If you're interested in utilizing a particular non-WebSocket method of communication, reach out to the Events Team for discussion and approval Your solution should be platform agnostic. For example, if you use filepaths in your submission, use Your solution must only communicate through WebSockets. Any communication between the client and server (or any two server workers), must utilize WebSockets.
- An exception to this rule is that communication with databases and files is allowed for accessing resources or for storage purposes.
+ An exception to this rule is that communication with databases and files is allowed for accessing resources or for storage purposes.
For example, you may use PostgreSQL as a database but not its `NOTIFY` command.
Working with subprocesses (through stdin/stdout or
+ The qualifier is a coding challenge that you are required to complete before registering for the code jam.
+ This is meant as a basic assessment of your skills to ensure you have enough python knowledge to effectively contribute in a team environment.
+
- Before being able to join the code jam, you must complete a qualifier which tests your knowledge in Python.
- The qualifier can be found on our GitHub
- and once completed you should submit your solution using the sign-up form.
+ Please note the requirements for the qualifier.
+
The chosen technology/tech stack for this year is WebSockets.
--
cgit v1.2.3
From 2d4ba1aa119b6a740ce103d7df39fb0492322252 Mon Sep 17 00:00:00 2001
From: Exenifix <89513380+Exenifix@users.noreply.github.com>
Date: Mon, 18 Jul 2022 23:24:03 +0300
Subject: Create docker-hosting-guide.md
---
.../guides/python-guides/docker-hosting-guide.md | 194 +++++++++++++++++++++
1 file changed, 194 insertions(+)
create mode 100644 pydis_site/apps/content/resources/guides/python-guides/docker-hosting-guide.md
(limited to 'pydis_site')
diff --git a/pydis_site/apps/content/resources/guides/python-guides/docker-hosting-guide.md b/pydis_site/apps/content/resources/guides/python-guides/docker-hosting-guide.md
new file mode 100644
index 00000000..3ae732e9
--- /dev/null
+++ b/pydis_site/apps/content/resources/guides/python-guides/docker-hosting-guide.md
@@ -0,0 +1,194 @@
+## Contents
+1. [You will learn](#you-will-learn)
+2. [Introduction](#introduction)
+3. [Installing Docker](#installing-docker)
+4. [Creating Dockerfile](#creating-dockerfile)
+5. [Building Image and Running Container](#building-image-and-running-container)
+6. [Creating Volumes](#creating-volumes)
+7. [Using GitHub Actions for full automation](#using-github-actions-for-full-automation)
+
+## You will learn
+- how to write Dockerfile
+- how to build Docker image and run the container
+- how to use docker-compose
+- how to make docker keep the files throughout the container's runs
+- how to parse environment variables into container
+- how to use GitHub Actions for automation
+- how to setup self hosted runner
+- how to use runner secrets
+
+## Introduction
+Let's say you have got a nice discord bot written in python and you have a VPS to host it on. Now the only question is how to run it 24/7. You might have been suggested to use *screen multiplexer*, but it has some disadvantages:
+1. Every time you update the bot you have to SSH to your server, attach to screen, shutdown the bot, run `git pull` and run the bot again. You might have good extensions management that allows you to update the bot without restarting it, but there are some other cons as well
+2. If you update some dependencies, you have to update them manually
+3. The bot doesn't run in an isolated environment, which is not good for security
+
+But there's a nice and easy solution to these problems - **Docker**! Docker is a containerization utility that automates some stuff like dependencies update and running the application in the background. So let's get started.
+
+## Installing Docker
+The best way to install the docker is to use the [convenience script](https://docs.docker.com/engine/install/ubuntu/#install-using-the-convenience-script) provided by Docker developers themselves. You just need 2 lines:
+```shell
+$ curl -fsSL https://get.docker.com -o get-docker.sh
+$ sudo sh get-docker.sh
+```
+
+## Creating Dockerfile
+To tell Docker what it has to do to run the application, we need to create a file named `Dockerfile` in our project's root.
+
+1. First we need to specify the *base image*. Doing that will make Docker install some apps we need to run our bot, for example the Python interpreter
+```dockerfile
+FROM python:3.10-bullseye
+```
+2. Next, we need to copy our requirements to some directory *inside the container*. Let's call it `/app`
+```dockerfile
+COPY requirements.txt /app/
+```
+3. Now we need to set the directory as working and install the requirements
+```dockerfile
+WORKDIR /app
+RUN pip install -r requirements.txt
+```
+4. The only thing that is left to do is to copy the rest of project's files and run the main executable
+```dockerfile
+COPY . .
+CMD ["python3", "main.py"]
+```
+
+The final version of Dockerfile looks like this:
+```dockerfile
+FROM python:3.10-bullseye
+COPY requirements.txt /app/
+WORKDIR /app
+RUN pip install -r requirements.txt
+COPY . .
+CMD ["python3", "main.py"]
+```
+
+## Building Image and Running Container
+Now update the project on your VPS and we can run the bot with Docker.
+1. Build the image (dot at the end is very important)
+```shell
+$ docker build -t mybot .
+```
+2. Run the container
+```shell
+$ docker run -d --name mybot mybot:latest
+```
+3. Read bot logs (keep in mind that this utility only allows to read STDERR)
+```shell
+$ docker logs -f mybot
+```
+If everything went successfully, your bot will go online and will keep running!
+
+## Using docker-compose
+Just 2 commands to run a container is cool but we can shorten it down to just 1 simple command. For that, create a `docker-compose.yml` file in project's root and fill it with the following contents:
+```yml
+version: "3.8"
+services:
+ main:
+ build: .
+ container-name: mybot
+```
+Update the project on VPS, remove the previous container with `docker rm -f mybot` and run this command
+```shell
+docker-compose up -d --build
+```
+Now the docker will automatically build the image for you and run the container.
+
+## Creating Volumes
+The files creating during container run are destroyed after its recreation. To prevent some files from getting destroyed, we need to use *volumes* that basically save the files from directory inside of container somewhere on drive.
+1. Create a new directory somewhere and copy path to it
+```shell
+$ mkdir mybot-data && echo $(pwd)/mybot-data
+```
+My path is `/home/exenifix/mybot-data`, yours is most likely different.
+2. In your project, store the files that need to be persistant in a separate directory (eg. `data`)
+3. Add the `volumes` construction to `docker-compose` so it looks like this:
+```yml
+version: "3.8"
+services:
+ main:
+ build: .
+ container-name: mybot
+ volumes:
+ - /home/exenifix/mybot-data:/app/data
+```
+The path before the colon `:` is the directory *on drive* and the second path is the directory *inside of container*. All the files saved in container in that directory will be saved on drive's directory as well and Docker will be accessing them *from drive*.
+
+## Using GitHub Actions for full automation
+Now it's time to fully automate the process and make Docker update the bot automatically on every commit or release. For that, we will use a **GitHub Actions workflow**, which basically runs some commands when we need to. You may read more about them [here](https://docs.github.com/en/actions/using-workflows).
+
+### Create repository secret
+We will not have the ability to use `.env` files with the workflow, so it's better to store the environment variables as **actions secrets**.
+1. Head to your repository page -> Settings -> Secrets -> Actions
+2. Press `New repository secret`
+3. Give it a name like `TOKEN` and paste the value
+Now we will be able to access its value in workflow like `${{ secrets.TOKEN }}`. However, we also need to parse the variable into container now. Edit `docker-compose` so it looks like this:
+```yml
+version: "3.8"
+services:
+ main:
+ build: .
+ container-name: mybot
+ volumes:
+ - /home/exenifix/mybot-data:/app/data
+ environment:
+ - TOKEN
+```
+
+### Setup self-hosted runner
+To run the workflow on our VPS, we will need to register it as *self hosted runner*.
+1. Head to Settings -> Actions -> Runners
+2. Press `New self-hosted runner`
+3. Select runner image and architecture
+4. Follow the instructions but don't run the runner
+5. Instead, create a service
+```shell
+$ sudo ./svc.sh install
+$ sudo ./svc.sh start
+```
+Now we have registered our VPS as a self-hosted runner and we can run the workflow on it now.
+
+### Write a workflow
+Create a new file `.github/workflows/runner.yml` and paste the following content into it (it is easy to understand so I am not going to give many comments)
+```yml
+name: Docker Runner
+
+on:
+ push:
+ branches: [ master ]
+
+jobs:
+ run:
+ runs-on: self-hosted
+ environment: production
+
+ steps:
+ - uses: actions/checkout@v3
+
+ - name: Run Container
+ run: docker-compose up -d --build
+ env:
+ TOKEN: ${{ secrets.TOKEN }}
+
+ - name: Cleanup Unused Images
+ run: docker image prune -f
+```
+
+Run `docker rm -f mybot` (it only needs to be done once) and push to GitHub. Now if you open `Actions` tab on your repository, you should see a workflow running your bot. Congratulations!
+
+### Displaying logs in actions terminal
+There's a nice utility for reading docker container's logs and stopping upon meeting a certain phrase and it might be useful for you as well.
+1. Install the utility on your VPS with
+```shell
+$ pip install exendlr
+```
+2. Add a step to your workflow that would show the logs until it meets `"ready"` phrase. I recommend putting it before the cleanup.
+```yml
+- name: Display Logs
+ run: python3 -m exendlr mybot "ready"
+```
+Now you should see the logs of your bot until the stop phrase is met.
+
+**WARNING**
+> The utility only reads from STDERR and redirects to STDERR, if you are using STDOUT for logs, it will not work and will be waiting for stop phrase forever. The utility automatically exits if bot's container is stopped (eg. error occured during starting) or if a log line contains a stop phrase. Make sure that your bot 100% displays a stop phrase when it's ready otherwise your workflow will get stuck.
--
cgit v1.2.3
From 2f7aecada0165428017b24baf03ba0a95049a932 Mon Sep 17 00:00:00 2001
From: Exenifix Every year we hold a community-wide Summer Code Jam. For this event, members of our community are assigned to teams to collaborate and create something amazing using a technology we picked for them. One such technology that was picked for the Summer 2021 Code Jam was text user interfaces (TUIs), where teams could pick from a pre-approved list of frameworks. To help fuel the creative process, we provide a specific theme, like Think Inside the Box or Early Internet. At the end of the Code Jam, the projects are judged by Python Discord server staff members and guest judges from the larger Python community. The judges will consider creativity, code quality, teamwork, and adherence to the theme. If you want to read more about Code Jams, visit our Code Jam info page or watch this video showcasing the best projects created during the Winter Code Jam 2020: Ancient Technology: Body 1
- Saturday, June 18 - Form to submit theme suggestions opensWednesday, June 29 - The Qualifier is releasedWednesday, July 6 - Voting for the theme opensWednesday, July 13 - The Qualifier closesCode Jams
-
+
multiprocessing.Pool()
/concurrent.futures.ProcessPoolExecutor()(
) is also exempted from this rule.
+ Lastly, working with subprocesses (through stdin/stdout or multiprocessing.Pool()
/concurrent.futures.ProcessPoolExecutor()
) is also exempted from this rule.
pathlib
to create platform agnostic Path objects instead of hardcoding the paths.multiprocessing.Pool()
/concurrent.futures.ProcessPoolExecutor()
) is also exempted from this rule.
+ Working with subprocesses (through stdin/stdout or multiprocessing.Pool()
/concurrent.futures.ProcessPoolExecutor()
) is also allowed.
pathlib
to create platform agnostic Path objects instead of hardcoding the paths.multiprocessing.Pool()
/concurrent.futures.ProcessPoolExecutor()
) is also allowed.
+
+ pathlib
to create platform agnostic Path objects instead of hardcoding the paths.multiprocessing.Pool()
/concurrent.futures.ProcessPoolExecutor()
) is also allowed.
How to Join
+
+ The Qualifier
+
+
+
Technology
Code Jams
+
Tags
', content)
+ self.assertInHTML('Wednesday, July 6 - Voting for the theme opensWednesday, July 13 - The Qualifier closesThursday, July 21 - Code Jam BeginsSunday, July 31 - Coding portion of the jam endsSunday, August 4 - Code Jam submissions are closedThe Qualifier
--
cgit v1.2.3
From 5dfe019745b53ceb8ce37f0db937d6e2a302f6d7 Mon Sep 17 00:00:00 2001
From: Hassan Abouelela