Background:

Some Python distros (OS X, Debian, Homebrew, others) want the default installation prefix for packages to differ from sys.prefix. OS X and Debian accomplish this by patching distutils itself, with special cases like `if sys.prefix == '/System/Library/...': actually_do_something_else()`. Homebrew accomplishes this by writing a `distutils.cfg` with:

    [install]
    prefix = /usr/local

The distutils.cfg approach is certainly simpler than shipping a patch, but has its own problems, because distutils doesn't differentiate the *source* of configuration options when resolving conflicts. That means that you can't do `python setup.py install --user` because it fails with the error "can't combine user with prefix, ..." without also specifying `--prefix=''` to eliminate the conflict.

Proposal:

I've included a patch for discussion, which uses the fact that the option_dict tracks the source of each option, and keeps track of the load order of each. In the case of an option conflict, the option that came from the lower priority source is unset back to None. If they come from the same source, then the same conflict error message is displayed as before.

Even if this patch is rejected as madness, as I expect it might be, official  recommendations on how to address the root question of `sys.prefix != install_prefix` would be appreciated.

Hmm... if it's only about --prefix vs. --user, we could let --user take precedence and issue a warning instead of an error.

`--prefix` vs `--user` is the only conflict I have encountered, but based on the way it works, it could just as easily happen with any of the various other conflicting options in install (install_base, exec_prefix, etc.), though that might not be very common.

There is a general question: If a Python distributor wants sys.prefix and default install_prefix to differ, what's the right way to do it? Setting it in distutils.cfg makes sense other than the conflicting option issues. Could there be a special `default_prefix` key that gets used as the final fallback (end of install.finalize_unix)?

I would really like to avoid having a warning on every install, since warning suggests that something has been done incorrectly, which in turn suggests that `distutils.cfg` is the wrong place to set the install prefix.

Ping! Any chance for feedback here? This behavior took me by surprise again today. :)

Can't we do something about this bug? I think that most python devs are ignoring the severity of this one, especially because it does break distribution of packages (or at least their testing)

On OS X the experience is awful as --user doesn't work at all and as a maintainer of many python packages I end-up with a case where installing packages for the current user doesn't work. It works well on all other platforms but not on OS X (when you have the brew python). 

We cannot really expect all the package developers to spend a lot of time creating new scenarios only for trying to bypass this bug.

For the sake of our Python users let's fix this and make the Python experience a good one, especially for people that do not have much experience with python.

Maybe Santa will get my message ;) Wish you happy holidays!

I do think this needs fixing. It's just that the patch is non-trivial and someone must take the time to review it.
Also, the patch should add a unit test to avoid regressions.

Distutils is now deprecated (see PEP 632) and all tagged issues are being closed. From now until removal, only release blocking issues will be considered for distutils.

If this issue does not relate to distutils, please remove the component and reopen it. If you believe it still requires a fix, most likely the issue should be re-reported at https://github.com/pypa/setuptools