Protect Your Python Projects: Avoid Direct setup.py Invocation for Ultimate Code Safeguarding!

Author(s): Anushka sonawane

Originally published on Towards AI.

It’s time to say goodbye to setup.py complexities and embrace efficient Python packaging with build frontends.

In this article, we’ll explore the challenges faced by distutils, setuptool and why invoking setup.py directly is no longer the best approach. Distutils and Setuptools were once significant, but they faced limitations when using setup.py directly. Distutils lacked modern features, while setuptools introduced complexity and portability challenges.

Shifting its approach,the setuptools team is transitioning away from providing a command line interface and focusing on being a library for creating packages. This change doesn’t mean setuptools is being deprecated, but rather, the direct execution of the setup.py file should be avoided.

Using dependency management tool like pip or Poetry serve as a game-changer here by automating the package building and installation process. Embracing its simplicity, portability, and future-proofing benefits, making them the key to success in modern Python packaging.

Traditionally, setup.py served as the entry point to the world of Python packaging. Developers would rely on it to define project metadata, dependencies, and installation instructions. The script’s invocation was as straightforward as running python setup.py install, and it seemed like the de facto method to package Python projects.

However, the story doesn’t end there. Personal anecdotes often reveal the limitations and quirks of relying solely on setup.py. Like many developers, I found myself entangled in a web of confusing dependency conflicts and version incompatibilities when working on a project that used distutils and setuptools. It felt like chasing shadows as one library update triggered a cascade of unexpected errors.

Imagine you’re building a package named “my_package” with a simple module “my_module.py.” Back in the day, your packaging journey might have looked something like this:

# setup.py
from distutils.core import setup

setup(
 name='my_package',
 version='1.0',
 py_modules=['my_module'],
 # Other metadata...
)

Innocent enough, right? But as your project swells in complexity, distutils reveals its limitations, this approach lacks many advanced features like dependency management and automatic installation.

Setuptools burst onto the scene with promises of advanced features and dependency management. setuptools is an improvement over distutils, but even it is being deprecated in favor of more modern packaging tools.

Let’s say you have a more complex project that requires external dependencies and additional metadata:

# setup.py
from setuptools import setup

setup(
 name='my_package',
 version='1.0',
 packages=['my_package'],
 install_requires=[
 'requests',
 'numpy',
 ],
 # Other metadata...
)

Setuptools initially improved Python development with features like streamlined package distribution, dependency management, and metadata enhancements. Running python setup.py sdist would create a source distribution for both distutils and setuptools However, as Python evolved, limitations emerged:

1. Global Installation Conflicts: Setuptools caused conflicts by installing different dependency versions globally, leading to compatibility problems among projects.
2. Complexity and Maintainability: As projects grew, managing setup.py files became complex, requiring updates across projects, and slowing development.
3. Isolation and Reproducibility: Setuptools struggled to isolate project dependencies, making consistent environments across systems difficult.
4. Lack of Standardization: Setuptools lacked a standardized project structure or configuration format, causing fragmentation in the project organization.

However, a notable drawback of setuptools is its inconsistency in handling dependency resolution across various platforms and environments. This inconsistency often leads to challenges when attempting to install a package on different systems. To tackle these issues, an alternative approach involves the use of build frontends and backends.

The challenges posed by traditional approaches like setuptools have led to the introduction of PEP 518 and PEP 517, along with the adoption of the pyproject.toml file. PEP 518 and PEP 517 brought forth a noteworthy advancement: the division between build frontend and backend. This allows developers to switch build tools easily based on needs. For example, different tools for local development, testing, or production builds.

Instead of sifting through a convoluted setup.py file, you manage your project’s configuration, dependencies, and build settings all in one centralized place, the pyproject.toml file. This single file becomes your command center, making your project’s management a breeze.

[tool.poetry]
name = "my_package"
version = "1.0"

[tool.poetry.dependencies]
python = "^3.6"
requests = "^2.25"
numpy = "^1.20"

[build-system]
requires = ["poetry-core>=1.0.0"]
build-backend = "poetry.core.masonry.api"

Here, the configuration is neatly organized and expressive. Dependencies are defined with version ranges, allowing for flexibility while ensuring compatibility. The [build-system] section is where the magic happens.The [tool.poetry] section defines project metadata and dependencies, while the [build-system]section specifies the build backend, which is responsible for executing the build process.

When you’re prepared to construct your package, the command ‘poetry build’ is all that’s needed.

The journey of Python packaging tools has been quite a ride. Back in the day, distutils and setuptools were the champions, doing their best to meet the needs of their time. But as the world of software development evolved, they found themselves a bit out of their league.

Poetry isn’t just about simplifying the tangled web of dependencies; it’s like fortifying your project’s very core. Imagine it as an extra layer of resilience that bolsters your project’s foundations, making them more robust and future-proof.

So, remember, while distutils and setuptools were the stars of their era, the stage now belongs to poetry and its companions!

Thank you for reading! I hope you found this post helpful. If you’d like to learn more, please check out the article that served as the cornerstone for this discussion. You can also connect with me on LinkedIn or Medium to stay up-to-date on my latest work.

Until next time,
Anushka!

Join thousands of data leaders on the AI newsletter. Join over 80,000 subscribers and keep up to date with the latest developments in AI. From research to projects and ideas. If you are building an AI startup, an AI-related product, or a service, we invite you to consider becoming a sponsor.

Published via Towards AI