@orivej, thanks for your PR! By analyzing the history of the files in this pull request, we identified @FRidh, @alexeymuranov and @bennofs to be potential reviewers.

You can use it in configuration.nix just fine, you just get collisions when using namespace packages in a Python 2.x environment.

Perhaps a better solution would be to fix withPackages to work correctly with namespace packages? Shouldn't the two __init__.py files have the same contents, so perhaps we can ignore collisions if the contents of the files don't differ?

You can use it in configuration.nix just fine, you just get collisions when using namespace packages in a Python 2.x environment.

Do you mean that it is fine to use with Python 3 and it should not be used only with Python 2?

Shouldn't the two __init__.py files have the same contents, so perhaps we can ignore collisions if the contents of the files don't differ?

They may not be identical. For example, /nix/store/12kp93bhx28ii1713p3xz9g0naz1hd3k-python2.7-configparser-3.5.0/lib/python2.7/site-packages/backports/__init__.py is

# A Python "namespace package" http://www.python.org/dev/peps/pep-0382/
# This always goes inside of a namespace package's __init__.py

from pkgutil import extend_path
__path__ = extend_path(__path__, __name__)

and /nix/store/nn8chrxk6dk2k6css8x7v171ry8kw6js-python2.7-backports.shutil_get_terminal_size-1.0.0/lib/python2.7/site-packages/backports/__init__.py is just

pkgutil import extend_path
__path__ = extend_path(__path__, __name__)

Note that the collisions do not occur with Python 3.x because of PEP 420.

@bennofs
Just ignoring the collisions is an easy solution but at the same time also increasing the risk of other serious collisions. Therefore I am not in favor of changing the default.

@orivej python.withPackages + namespace packages + Python 2.x => collisions.

All other situations work fine.

@FRidh yes that is why I was suggesting to ignore them only in the case of identical contents. But turns out that this is not enough for namespace packages, so I guess this can't really be fixed.

This is a deficit in the python 2 packaging approach, it is good that nix gives an error here and does not blindly allow a package to override the files of another package. It is similar to a merge conflict: there is sometimes no automatic solution to it, manual intervention is required.

Thanks, I updated this pull request.

Usually file collisions indicate packaging problems, but with Python 2 buildEnv environments collisions between __init__.py in namespace packages are expected and there is nothing to do but to enable ignoreCollisions = true. This should be reflected in the manual.

@FRidh can we perhaps detect namespace packages and strip comments from __init__.py if it matches the "official" __init__.py for namespace packages? I think buildEnv allows collisions between files with identical contents, so that should prevent the conflict in 99% of the cases I would assume.

For the remaining namespace packages not detected by this, we could fix up the __init__.py to match the officially recommended one in the build phase.

@FRidh is the documentation good to go?

I've just pushed 8d491ec