Shulou(Shulou.com)06/03 Report--

This article shows you how to write Makefile for the Python project. The content is concise and easy to understand. It will definitely brighten your eyes. I hope you can get something through the detailed introduction of this article.

As a fan of Makefiles, I use them in almost every part-time project. And I also advocate using it in work projects.

For open source projects, Makefiles lets code contributors know how to build, test, and deploy the project. And, if you use Makefiles correctly, they can greatly simplify your CI/CD process scripts. Because you simply need to call the corresponding make command. Most importantly, Makefiles can simplify your development work.

For Python projects, I always use virtual environments, so I use two different Makefiles strategies:

Suppose the make command is executed in a virtual environment

Encapsulate commands in a virtual environment through make commands

Suppose the make command is executed in a virtual environment

Let's take a look at a very simple Makefile file that allows you to build, test, and publish Python projects:

All: lint test .PHONY: test test: pytest .PHONY: lint lint: flake8 .PHONY: release release: python3 setup.py sdist bdist_wheel upload clean: find. -type f-name *. Pyc-delete find. -type d-name _ _ pycache__-delete

These pieces of code are so straightforward that all potential contributors immediately know where the entrance to your project is.

Assuming you already have a virtual environment, you need to activate it first, and then run the make command:

$. Venv/bin/activate $make test

The inconvenience, of course, is that every shell window you have has to activate the virtual environment manually. So it's troublesome when you use tmux to activate a new terminal window or put vim in the background to run.

Activating a virtual environment in a make command seems difficult because every piece of code and even every command runs in its own shell. But we'll see a way around this limitation later, such as using the .One shell flag, but this doesn't solve the problem of new code snippets running on the new shell.

Encapsulate the calling command of the virtual environment in the make command

The second method basically solves the problem of activating the virtual environment in the make command. I learned this method from makefile.venv [2], and I simplified it a little bit:

# system python interpreter. Used only to create virtual environment PY= python3 VENV = venv BIN=$ (VENV) / bin # make it work on windows too ifeq ($(OS), Windows_NT) BIN=$ (VENV) / Scripts PY=python endif all: lint test $(VENV): requirements.txt requirements-dev.txt setup.py $(PY)-m venv $(VENV) $(BIN) / pip install-upgrade-r requirements.txt $(BIN) / pip install-upgrade-r requirements-dev.txt $(BIN) / pip install-e. Touch $(VENV) .PHONY: test test: $(VENV) $(BIN) / pytest .PHONY: lint lint: $(VENV) $(BIN) / flake8 .PHONY: release release: $(VENV) $(BIN) / python setup.py sdist bdist_wheel upload clean: rm-rf $(VENV) find. -type f-name *. Pyc-delete find. -type d-name _ _ pycache__-delete

From a functional point of view, this Makefile is similar to the previous one, but the code looks more complex. So let's take a look at how it works.

If the virtual environment has been activated, or the packages such as pytest and flake8 have been installed in the system Python environment, then we can call them directly. But now, in the new Makefile file, we explicitly use the absolute path in the virtual environment to invoke them. To ensure the existence of a virtual environment, each piece of code relies on the item $(VENV). This ensures that an up-to-date virtual environment is currently available.

This scheme works because when we implement it. When venv/bin/activate, the original virtual environment is to put its own absolute path into the environment variable. So every time you call Python or other packages, you install them in a virtual environment.

Although the Makefile file has become a bit complex, when we want to test the code, we just need to simply execute the command:

$make test

That's it, we don't need to care about whether the virtual environment is installed or not. If you don't need to support Windows, you can even remove Windows-related parts from Makefile. In this way, the Makefile file is not difficult to understand even for people who don't use it very much.

Which is better?

I think the second option is more convenient. Although I have been using the first method happily for several years, I have only recently learned the second method. I really didn't notice this method before. But I've noticed the first method used by almost all Python projects that use Makefile, and I want to know why.

Kingname comments

I often use Makefile in Python projects and Golang projects, in which the Python project is mainly used to delete _ _ pycache__, while in the Golang project, because I am using VSCode to develop, there is a problem with its lint, so after the code is written, I will use Makefile to execute a gofmt command to format all .go files.

But Makefile has a very retarded place-indentation in it must use tabs, not spaces. So when I want to write Makefile, I also have to use vim to write. Because my PyCharm has been set to change all tabs into spaces. And if you mix spaces in the indentation of Makefile, it will report an error.

The above is how to write Makefile for the Python project. Have you learned the knowledge or skills? If you want to learn more skills or enrich your knowledge reserve, you are welcome to follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.