Implement some geometric shapes as plotted on a cartesian plane as Python classes. Provide methods for area, length and others. The code stubs and tests have been provided.
Read the README
! This file is in every repository, by convention. It
describes how to install the package, test it, and any related
documentation.
To setup your workstation (shell, environment, packages), you will need to do the following:
pyenv
is used to manage multiple versions of python on your system. It
should be installed by the operating system package manager.
sudo apt-get install pyenv # Ubuntu/Debian
sudo pacman -Syu pyenv # Arch
pyenv install 3.9.6
pyenv global 3.9.6
Verify you're using the correct versions of pip
and python
by
running:
pip --version
pip install poetry
This is used to manage virtual environments - 'python-in-a-folder' groups of installed packages.
poetry install
This will install all of the requirements you specify in
pyproject.toml
file.
In order for emacs
to find code definitions and give you
suggestions, we need to activate the virtualenv we've created.
Get the path of the virtualenv from your terminal:
poetry env info --no-ansi \
| grep -E 'Path.*virtualenvs' \
| tr -s ' ' \
| cut -d ' ' -f 2
Next we will activate this environment, to make emacs aware of the packages we've installed:
Run M-x pyvenv-activate <RET>
, provide the output of the command
above, then hit <RET>
once more. If you are working on a python file
and want to reload it, run s-; w r
.
That reads as: super + ;
together, release super, followed by w
,
followed by r
). When you see <RET>
that means press Enter
.
We are using lsp-pyright
. Here is the snippet you need in your
.emacs
configuration:
; Python
(add-hook 'python-mode-hook #'(lambda ()
(require 'lsp-pyright)
(lsp)))
; `s-l` is often swallowed by wm, remap it to `s-;`
(setq lsp-keymap-prefix "s-;")
poetry run pytest
Do this often to make sure you are on the right track. As you build more of your code on top of other code, you always want to know how the building blocks behave under each other.
The next part of your workstation, is how you save, backup, and share your code with others.
Your shell is the program that lets you type and run commands, set environment variables, send data between two programs, and much more.
The most common shells are bash
, sh
, and zsh
. I prefer zsh
together with oh-my-zsh
to provide a very comfortable interactive
experience. sh
is not recommended for interactive use, but is
available on any UNIX/linux system you work with and is the most
compatible. bash
is the default on most systems, and is very similar
to zsh
.
Git is similar to the shell - mastering it is very important! As a
developer, you are often not working alone, and it is necessary to share
your code with others. git
is one of a long line of different tools
for managing source code. Managing code can become a very difficult
task, unless you carefully and frequently commit those changes to
something that keeps different versions of it for you.
Anything you do with git
should always start and end with running:
git status
This gives you an overview of the status of your local clone
. A
clone
is a local directory that has been matched up with a Github
project.
git
does this by way of commits
to branches
. A commit
is
broadly-speaking two things: a message intended for humans to read, and
a changeset
, which is a collection of files that were added, removed,
or modified. A branch
keeps track of all of the changes you make by
chaining together commits
.
git commit [-m "Optional message"]
# Shortcut:
# gc
If you don't specify a message with -m "..."
, it will open an editor
for you to author your message in!
When you make commits, they are only available to you, on your
workstation, until you push
them to another computer. While git
is
designed to allow people to push
and pull
code in all sorts of ways,
it is most often used in a centralized
way. For us, this means using
Github as the center of where both of us push
to and pull
from.
When you push
, you usually push
a specific local branch
to a
remote branch
. The remote and local branches usually share the same
name. For example, you may be working on a branch called main
locally. After making a few commits, you want to synchronize the changes
with the central server - Github. So you run:
git checkout main
git push origin main
# Shortcut:
# gco main
# ggpush
The name origin
here is the default name for where you cloned
your
local repository from.
What this means is that for a repository that I own on github, I can push and pull branches, made of one or more commits.
If another contributer wants to do the same, they will need to be aware of the changes other people are doing. To get an update of all of the changes people have been making on a repository, I can run:
git fetch
# Shortcut:
# gf
Then if I want to update my local copy of main
, run:
git checkout main
git pull origin main
# Shortcut:
# gco main
# ggpush