# Practices for setuptools-less usage in python

The general and pretty much standard way of packaging a python distribution is to use setup.py, however I've seen an approach where the code is not installed, it's just invoked as a script, and any adjoined library (that is, it is part of the same codebase, not one that can be retrieved from pypi) is eventually made accessible via updating sys.path. A lot can be argued if this is good or bad practice, but it works, it requires no pip install and it's a fact in some places. I was wondering if any of you saw this approach used, its drawbacks, and if one uses this approach, what are the options to achieve functionalities such as resource lookup (e.g. I want icons) apart from using the current __file__ path to find the location of stuff, or if there are better ways to achieve the same result (no pip install)

Pip/setuptools is part of the core Python system. There is no reason to avoid them, except that the setuptools documentation makes it difficult to get started.

There are a few Python features that can make installation via pip less necessary:

• relative imports, like from .myproject import foo, bar. This is still a good idea even when using pip.
• manual path manipulation based on the __file__.
• manual PYTHONPATH manipulation.

What a proper installation offers is ease of use and portability. For example:

• being able to distribute your application as pre-built wheels or eggs
• being able to load resources from embedded package data, without having to manipulate paths yourself (also note that when running an egg, no paths exist)
• being able to track and install dependencies
• being able to install and run across platforms

An example for the latter point: I had an application that could be downloaded and run directly or installed via pip. With manual installation, users would have to point their PATH to the script. While this worked fine on Unix-ish systems, Windows users had to perform extra steps: they would have to manually invoke Python like python3 C:\path\to\foo or would have to place a foo.bat file in their PATH to run it.

By turning the application into a proper module and using setuptool's entrypoints feature, all of that could be automated. Installation via pip (or python setup.py install) is now required, but it works for everyone.

You may have totally different requirements and constraints. E.g. if you control the deployment of your code you can use or ignore whatever tools you (dis-)like. But considering that three lines of boilerplate are literally everything you need to start benefiting from Pip, there's little reason not to use these Python features:

from setuptools import setup
setup('project-name',
packages=['yourpackage'])

• Some places actively don't want to install. They have one repository they use directly – Stefano Borini Sep 19 '18 at 10:05
• @StefanoBorini Such a place would also imply that I cannot have external dependencies, which is an incredibly inefficient way to write Python software. The language is nothing without its ecosystem. Note also that venv is part of the standard library, so it's easy to do an isolated installation like python3 -m venv --system-site-packages venv; source venv/bin/activate; python3 -m pip install -e . – amon Sep 19 '18 at 10:26
• You can definitely have external dependencies: you create a virtualenv that contains all the dependencies and codifies your runtime once and for all. This is actually a legal requirements in some companies that follow safety standards. – Stefano Borini Sep 19 '18 at 12:17
• But if I already have a virtualenv then I can simply install my code into that virtualenv as well?? – amon Sep 19 '18 at 12:35
• No, because the virtualenv is provided by a third party, it's pretty much considered readonly and it's not supposed to be modified in any way. Plus, if you use this approach, now you have to consider that of the maybe a hundred programs you have developed, you must install them all. If your checkout is your deployment, you just need the checkout. – Stefano Borini Sep 19 '18 at 12:57