In Python Packaging, when you are giving for your project a list of dependencies, the right approach is to do whatever works for the majority of your users because there's a plethora of techniques used by people out there to deploy Python software.

That's the case for 2 main reasons:

Most Python projects can be deployed in different operating systems - and unless you're doing a specific packaging work for each one of them, you are doomed to provide a good enough generic package. There are different installers with different approaches and your Python projects should try to be compatible with all of them.

Some of users will have issues with your projects, you have to accept this fact and just make sure you provide enough documentation and hints for them to work around those issues.

This blog entry tries to summarize my current knowledge on what's the best way to defining dependencies - I hope I'll have some feedback so I can update it with better techniques. Also, note that I have not applied this to all my projects. I should.

So if you disagree on my approach please comment !

Note I am not talking about Virtualenv on purpose here, to avoid extra complexity.

Nature of your project The first thing to think about is the nature of your project. They are two kind of projects in the Python world that can be installed by users: library & tools that will be used in conjunction with other Python projects. End-user applications that are using a plethora of other Python projects themselves. The first category is what we create most of the time: utility modules, extensions for some frameworks, library to connect to a database, etc. The second is a bit specific. It can be a framework, a website or a desktop application - Most of the time it's driving the whole Python environment it's running in and dictates what should be installed.