Philip Semanchuk <phi...@semanchuk.com> writes: > Our project uses some libraries that were written by 3rd parties (i.e. > not us). These libraries fit into a single Python file and live in our > source tree alongside other modules we've written.
Why in the same source tree? They are maintained separately, so you shouldn't be duplicating them in your source. > When our app is distributed, they'll be included in the installation. That can be done simply by having the third-party's standard distribution included with yours, and use it *if it's not already installed* on the user's system. > In other words, they're not prerequisites that we'll make the user > install, and they won't live in site-packages. What if they already *do* exist in site-packages? Why not install them there yourself? > PEP 8 <http://www.python.org/dev/peps/pep-0008/> says the following: > > Imports should be grouped in the following order: > 1. standard library imports > 2. related third party imports > 3. local application/library specific imports > > > I'm not sure in which category to place local, 3rd-party modules like > configobj. They are third-party imports; category 2. > Clearly, they belong in category 3 since they're local. They shouldn't be local, since they're not part of your application's code base; they're maintained as separate distributions (even if you bundle them together when distributing your work). Moreover, if there is an update to configobj by its current maintainers, and I have installed three (or seven, or seventy-three) applications using it, I want *one* update into site-packages to fix it for *all* of those applications. Not have to fuss about with all the duplicated copies, and worry about which ones have been missed (or, worse, *not* worry and the be confused over why the bug is still occurring in some applications). > Clearly, they also belong in category 2 since they're 3rd party > modules, and explicitly labeling an imported module as "this is code > we didn't write" is useful. But I've always reserved category 2 for > external libraries (e.g. numpy, wxPython, Twisted, PIL, etc.). Third-party libraries *are* external libraries. Please, for the sake of your users, keep them so. You can *install* them at the same time, but please don't *duplicate* them, forking them as though they're part of your code base. -- \ “We are not gonna be great; we are not gonna be amazing; we are | `\ gonna be *amazingly* amazing!” —Zaphod Beeblebrox, _The | _o__) Hitch-Hiker's Guide To The Galaxy_, Douglas Adams | Ben Finney -- http://mail.python.org/mailman/listinfo/python-list
