sourcery-ai / python-best-practices-cookiecutter Goto Github PK

In other words: do reusers have to mark the files in it "Copyright (c) 2019 Sourcery" and does their software have to reproduce it in their UIs?

I'm asking because I reused parts of it as a base for a little hack project.
The files don't form part of the software, but are more configuration of the tools that help build it. But I am redistributing.

Sorry, maybe I don't get it, but why is no setup.py defined for the module?

For example:

def main():
    set_python_version()
    # Initialise git repo
    os.system('git init')
    # Install dependencies
    os.system('pipenv install --dev')
    # Setup pre-commit and pre-push hooks
    os.system('pipenv run pre-commit install -t pre-commit')
    os.system('pipenv run pre-commit install -t pre-push')
    print(SUCCESS + "Project successfully initialized" + TERMINATOR)

As of isort 5.0 (released July 4, 2020), the --recursive flag is no longer necessary. Adding results in the following warning:

/home/runner/.local/share/virtualenvs/spectra-KcgPObjh/lib/python3.9/site-packages/isort/main.py:1206: UserWarning: W0501: The following deprecated CLI flags were used and ignored: --recursive!

While not pressing, this should probably eventually be removed from .github/workflows/test.yml

Add optional uploading of the code coverage report to codecov.io

Sample change to .github/workflows/test.yml

<       - run: pipenv run pytest --cov --cov-fail-under=100
---
>       - run: pipenv run pytest --cov --cov-fail-under=100 --cov-report=xml
>
>       - name: Upload Coverage to Codecov
>         uses: codecov/codecov-action@v1

Description

This cookiecutter template will generate a repository that uses black v20.8b1.

According to this issue, this version of black is not compatible with newer versions of click and will throw an error upon execution of black.

Recommendation

Updating the default black version to be 22.3.0 for this template.

The PEP 561 has a lot of best practices when we talk about the distribution and packaging type Information in a Python application.

A very simple good practice is to add a py.typed file in the project directory.
This makes it possible not to have stub files and to embed the typing directly in the .py files

A feature request instead of an issue, but it would be nice if we could have cookiecutter prompt the user to choose pipenv or poetry. Poetry uses the upcoming "standard" of a pyproject.toml file.

Creating this issue for a PR I'd like to submit. Instead of using pipenv, an approach my team and I have been enjoying moreso recently has been to create a make command named refresh-dev that idempotently creates a virtual environment for a developer, compiles all necessary and local dev-oriented requirements from requirements*.in using pip-tools pip-compile command to to generate requirements*.txt files, finally installing Python package dependencies from those files.

Here's a sample of what the our Makefiles look like for each Python-heavy repository we work in:

pip-compile: ## runs pip-compile to build requirements files
	@echo "Pinnning Versions"
	./.venv/bin/python -m pip install --upgrade pip
	./.venv/bin/python -m pip install pip-tools
	./.venv/bin/pip-compile requirements.in -o requirements.txt --upgrade --no-emit-index-url --generate-hashes
	./.venv/bin/pip-compile requirements-dev.in -o requirements-dev.txt --upgrade --no-emit-index-url --generate-hashes

pip-install: ## Install requirements*.txt
	@echo "Installing All Requirements"
	./.venv/bin/python -m pip install -r requirements.txt
	./.venv/bin/python -m pip install -r requirements-dev.txt

refresh-dev: ## Idemponently setup or refresh local dev environment
	@echo "Refreshing Dev Virtual Env"
	rm -fr ./.venv
	python3 -m venv .venv
	chmod +x ./.venv/bin/activate
	./.venv/bin/activate
	make pip-compile
	make pip-install
	source ./.venv/bin/activate

When the dev first checks out the repo, they'll need to configure the appropriate version of Python for their project. I use pyenv and add a .python-version file at root of repo with the version of Python we're targeting per the context of the project and the context of the eventually production environment.

For example, pyenv shell 3.8.12 will write 3.8.12 in a file named .python-version.

After that, all I or any other dev on the team needs to do is run these commands at the root of their freshly-cloned repo:

make refresh-dev

They may need to manually activate the virtual environment at the end of the process. If they need to add a new dependency, they can simply add the name of the dependency to the appropriate requirements*.in file, then run make pip-compile and pip-sync or make pip-install to refresh their dev environment without having to rebuild it from scratch (although I usually run make refresh-dev just to make sure all packages will work with each other and to start with a clean slate).

Steps to Reproduce

# create a project
cookiecutter gh:sourcery-ai/python-best-practices-cookiecutter

# install dependencies
pipenv install --dev

# set remote and push to github
git remote add origin [email protected]:user/repo.git
git add .
git commit -m "Initial commit
git push

Navigate to GitHub actions and see the Test workflow fail.

Here is an example

Expected Result

Should work out of the box.

wemake-python-styleguide is the strictest python linter.
Inside it is just a flake8 plugin, which you already use.

Repo: https://github.com/wemake-services/wemake-python-styleguide
Docs: https://wemake-python-stylegui.de/en/latest/