This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author minrk
Recipients dstufft, eric.araujo, minrk
Date 2014-08-24.22:32:24
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1408919544.9.0.398406846461.issue22269@psf.upfronthosting.co.za>
In-reply-to
Content
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.
History
Date User Action Args
2014-08-24 22:32:25minrksetrecipients: + minrk, eric.araujo, dstufft
2014-08-24 22:32:24minrksetmessageid: <1408919544.9.0.398406846461.issue22269@psf.upfronthosting.co.za>
2014-08-24 22:32:24minrklinkissue22269 messages
2014-08-24 22:32:24minrkcreate