I don't think so, not if you're building a language package manager. I think you should look carefully at what npm and cargo do, and try your best to avoid wha

I don't think so, not if you're building a language package manager. I think you should look carefully at what npm and cargo do, and try your best to avoid what os package managers do. Unfortunately, half the problem with python is that system level package managers want to rule the world, and not allow you to have 'user level' packages (ie. libraries) installed. pygtk, for example, can't be pip installed. In fact, you can't actually (afaik) even use it from a virtualenv without modifying sys.path. The most annoying thing about pip for me is that it isn't a 'complete story' in many cases. You have to actually install system level python-foo packages, which are not pinned in any meaningful way, and then hope that your application works. Repeatable builds should be the goal of a python package manager; and that means being able to install specific versions of python (and c) libraries, in a way that is idempotent to the underlying OS; whatever it is. OS level package managers solve a different problem; providing a single consistent packaged version of libraries and applications for users; having repeatable builds to generate those packages is a different problem, and, as evidenced by the huge amount of work the debian folk are putting into repeatable builds, not a trivial one; certainly not one that dpkg has already solved.