nevow

  1. Bug #812537
  2. Comment #3

Comment 3 for bug 812537

Revision history for this message
Zooko Wilcox-O'Hearn (zooko) wrote :

Ivan Kozik asked me on Stack Overflow to explain why it could matter, for Python packages in general, whether they import themselves when building. I managed to explain the ways that it can be a problem better this time around than before:

http://stackoverflow.com/questions/458550/standard-way-to-embed-version-into-python-package/7071358#7071358

Below I'll copy and edit what I wrote there:

If your setup.py is being executed in a freshly created Python process, and your current working directory is the directory that contains the version of your project that it is building, and any dependencies that your project imports when it is imported are already installed, then it will work.

This is the common way that programmers run setup.py, so they often think it is the only way. But there are other ways that setup.py gets evaluated! Tools like py2exe run a single Python process and then load and execute the setup.py scripts from one project after another (while packing them all together). Suppose that some of the Python code that ran before your setup.py script imported a different version of your module. In that case, "import yourniftymodule" in your setup.py would find that *different* version in your sys.modules. (This has happened to me with Nevow.)

Another problem is if the user is using a tool like setuptools or pip to install your package. Such a tool needs to do two things for packages that declare dependencies: 1. build this package, 2. install (first building, if necessary) its dependencies. Now, what order should the tool do this in?

It can't (in the setuptools/pip/virtualenv system of today) even know what the deps are until it evaluates your setup.py. Also, if it tried to do full depth-first and finish installing all deps before it builds this package, it would get stuck if there were circular deps. But if it tries to build this package before installing the dependencies, then if you import your package from your setup.py, it will not necessarily be able to import its deps, or the right versions of its deps.