Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update the development guide with the correct minimum Python version #7653

Merged
merged 1 commit into from
Nov 14, 2024
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
31 changes: 16 additions & 15 deletions DEVELOPMENT_GUIDE.md
Original file line number Diff line number Diff line change
Expand Up @@ -20,8 +20,8 @@ Gitpod is free for 50 hours per month - make sure to stop your workspace when yo
## Environment Setup
### 1. Prerequisites (Python Virtual Environment)

AWS SAM CLI is mainly written in Python 3 and we support Python 3.7 and 3.8.
So having a Python environment with aforementioned versions is required.
AWS SAM CLI is mainly written in Python 3 and we support Python 3.8 and above.
So, having a Python environment with this version is required.

Having a dedicated Python virtual environment ensures it won't "pollute" or get "polluted"
by other python packages. Here we introduce two ways of setting up a Python virtual environment:
Expand Down Expand Up @@ -163,26 +163,27 @@ contribute to the repository, there are a few more things to consider.

### Make Sure AWS SAM CLI Work in Multiple Python Versions

We support 3.7 and 3.8 versions. Our CI/CD pipeline is setup to run
We support version 3.8 and above. Our CI/CD pipeline is setup to run
unit tests against all Python versions. So make sure you test it
with all versions before sending a Pull Request.
See [Unit testing with multiple Python versions](#unit-testing-with-multiple-python-versions-optional).
See [Unit testing with multiple Python versions](#unit-testing-with-multiple-python-versions-optional).
This is most important if you are developing in a Python version greater than the minimum supported version (currently 3.8), as any new features released in 3.9+ will not work.

If you chose to use `pyenv` in the previous session, setting up a
different Python version should be easy:

(assuming you are in virtual environment `samcli38`)
(assuming you are in virtual environment named `samcli39` with Python version 3.9.x)

```sh
# Your shell now should looks like "(samcli38) $"
pyenv deactivate samcli38 # "(samcli38)" will disappear
pyenv install 3.7.10 # one time setup
pyenv virtualenv 3.7.10 samcli37 # one time setup
pyenv activate samcli37
# Your shell now should looks like "(samcli37) $"
# Your shell now should look like "(samcli39) $"
pyenv deactivate samcli39 # "(samcli39)" will disappear
pyenv install 3.8.9 # one time setup
pyenv virtualenv 3.8.9 samcli38 # one time setup
pyenv activate samcli38
# Your shell now should look like "(samcli38) $"

# You can verify the version of Python
python --version # Python 3.7.10
python --version # Python 3.8.9

make init # one time setup, this will put a file `samdev` available in $PATH
```
Expand Down Expand Up @@ -255,9 +256,9 @@ We also suggest to run `make pr` or `./Make -pr` in all Python versions.
#### Unit Testing with Multiple Python Versions (Optional)

Currently, SAM CLI only supports Python3 versions (see setup.py for exact versions). For the most
part, code that works in Python3.7 will work in Python3.8. You only run into problems if you are
trying to use features released in a higher version (for example features introduced into Python3.8
will not work in Python3.7). If you want to test in many versions, you can create a virtualenv for
part, code that works in Python3.8 will work in Python3.9. You only run into problems if you are
trying to use features released in a higher version (for example features introduced into Python3.9
will not work in Python3.8). If you want to test in many versions, you can create a virtualenv for
each version and flip between them (sourcing the activate script). Typically, we run all tests in
one python version locally and then have our ci (appveyor) run all supported versions.

Expand Down
Loading