It would be useful if setup.py instances had an option to ignore
~/.pydistutils.cfg or substitute it with another file. For example, this
would be highly useful to people who maintain a system site-packages
directory along with one in their own home directory.

I'm working on this (at the pycon sprint).

The attached patch implements a command-line option to disable loading
of $HOME/.pydistutils.cfg.

After talking to Martin Loewis, I decided not to implement the override
part, because if it's a one-time thing you can just pass the settings on
the command line; and if you have two configurations you want to use
frequently, you can just use two user accounts.

The hard part was writing tests, since the existing code was untested
and is environment-sensitive. See the comments in the patch re. what I
still don't like about it. I would like to have a less evil test setup
and teardown, but I'm going on vacation tomorrow so I won't be able to
look at this again until April.

That is up to you of course, and being able to ignore is better than
nothing. But creating a new account is not really an option for
everyone. On the system I would like to use this feature the most, I am
not a system administrator, so I cannot create new user accounts. I
maintain a directory for production use of people in my workgroup. I
also maintain my own for testing and development.

Thanks for your work on this patch. At least being able to use
--no-user-cfg will be very helpful.

We thought that the added value for specifying another configuration
file is relatively minor: if you have to set command line options
anyway, just put anything you want to specify on the command line,
rather than into the other configuration file.

Out of curiosity: what kinds of settings do you put into the
configuration file?

Here's an example of a configuration file I use:

====
[build_ext]
include_dirs = /nfs/acari/mh5/include/python2.5:/nfs/acari/mh5/include

[install]
prefix = ~
exec_prefix = ~/arch/$ARCH
install_platlib = $platbase/lib/python$py_version_short
install_purelib = $base/lib/python$py_version_short
install_scripts = $platbase/bin

[easy_install]
install_dir = $platbase/lib/python$py_version_short
script_dir = $platbase/bin
====

I am installing software on a filesystem that is shared between
different architectures (i386 and x86_64), so I must have separate
directories for extensions on each platform. Because of this, using
--home=~ doesn't cut it.

I don't want to be a pain, if the --no-user-cfg can go in sooner, that
would be very helpful.

Here's an alternate patch that uses a bit of dependency injection to
avoid the need for monkeypatches in setup/teardown. This means some
trivial changes to Distribution.__init__(). I slightly prefer this
approach, but some might argue it's an example of "test logic in
production".

I also added a line about the new option in Doc/install/index.rst.

Since I don't have checkin privileges, I will stop here. Can somebody
upstream (Martin?) please take one of these patches and apply it? Or
suggest further changes to either of these patches? Or ... ?
Thanks.

Both versions of the patch have a problem, in that the Distribution
object is looking for an option directly in sys.argv. At the very
least, this should be looking at the 'script_args' attribute of the
Distribution instead (if not actually parsing the command line enough to
find the option).

Phillip, thanks, I missed that script_args is always passed by
core.setup(). I'm replacing the patches with two new versions that check
self.script_args instead of sys.argv (and assumes false if for some
reason script_args isn't passed).

We can't check for it in Distribution.parse_command_line() because that
doesn't get called until after loading the config files.

and here's the revised version of the dependency-injection approach.

I much prefer the simpler of the two patches - better to monkeypatch in
the tests than adding complications to the already over-complicated
distutils.dist. I don't find monkeypatching in tests to be horrible at
all, but if it really bothers you, just create a temporary directory for
HOME to point to, and test a Distribution subclass with an overridden
check_environ.

By the way, the patch could be simpler if you just made the "if 'HOME'
in os.environ" read "if not self.no_user_cfg and 'HOME' in os.environ",
rather than reworking the entire code region. On the other hand, if
you'd rather have ultra-clean unit tests, you could split the
functionality of find_config_files() into two methods: one that creates
the candidate list and the other that filters it by existence.

Personally, my vote is to keep the monkeypatching in the tests and make
the barest minimal changes to the Distribution class though.

Phillip, here's another revision of the monkeypatch-in-setUp() approach,
simplified per your suggestions.

It looks like you can drop the change to distutils.core, too, since
it's just a change in the comment, and the changed comment is
inaccurate, AFAICT. Apart from that, it looks good.

In what way is the comment in core.py inaccurate? I only added the
phrase "and override config files", which is an important side effect of
parse_command_line().

Oh, I thought you meant that it overrides *which* config files --
i.e., implied that it was handling --no-user-config.

Is this going to make the 2.6 release? The lack of this option causes
grief on MacPorts. Just wondering if there's anything I could do to move
this along, as a cursory reading shows everyone to be happy...

Formally, the beta deadline has passed, so no new features can be
admitted. If pje is now happy with the code as it stands (not clear from
the last message), I can ask for permission to commit it, anyway.

I'm good with it; the issue with the comment in core.py was my only
remaining objection.

Whatever happened with this? I don't see it mentioned in the NEWS file
for the 2.6 line.

Unfortunately, it missed the deadlines (i.e. nobody checked it in in
time). I'll look into it.

Any update?
Is this patch going to be included in 2.6.x/3.0.x in near future?

I am taking over this issue (I am figuring out you are OK with this
Martin) and put it in my work pile so it goes in 2.7

I've simplified the tests so they just check that [.]pydistutils.cfg is
taken or not taken, depending if the option is used.

I've also made sure the option is just looked in the global options,
because the patch was implying that a command local option with the same
name could work.

Done in r75893 and r75895.

Thanks a lot Paul !

The --no-user-cfg option works for me in Python 2.7, but it does not seem to be in Python 3.2 or 3.3:

error: option --no-user-cfg not recognized

Am I doing something wrong, or was this feature only added to Python 2.7?

Andrew, comments to closed issues are usually ignored. I suggest you open a new issue about this. A quick glance suggests that the code for this feature is not in Python 3. It may be that it was lost when, during the 2.7 development cycle, it was decided to not allow new features to Distutils and a number of changes were reverted. There have been some other cases of Distutils changes that were lost in Python 3.2+ because of this.

Confirmed - and to be included in bpo-19544.

Here's a patch to restore the --no-user-cfg switch to 3.4. If someone will take a quick look at the patch for sanity, I can apply it.

Patch looks good to me.

New changeset c35311fcc967 by Andrew Kuchling in branch 'default':
Issue bpo-19544 and Issue bpo-1180: Restore global option to ignore ~/.pydistutils.cfg in Distutils, accidentally removed in backout of distutils2 changes.
http://hg.python.org/cpython/rev/c35311fcc967