Allow "true" values for pip.conf negative options (no-cache-dir and no-compile)

[CharlesB2]

• Pip version: 9.0.1
• Python version: 3.5.2
• Operating system: Ubuntu 16.04 LTS

Description:

Trying to disable cache dir, I see in the docs that I need to set falsy values to no-cache-dir, which is counter intuitive: no-cache-dir is false, it's a double negation, and it's difficult to figure out that it actually disables the cache dir.

Trying to set it to true gives the error below.

What I've run:

In pip.conf, if I set no-cache-dir to true, in the intent of disabling cache dir:

[global]
no-cache-dir = true

and then running e.g. pip list gives:

[...]
Traceback (most recent call last):
  File "/usr/local/bin/pip3", line 11, in <module>
    sys.exit(main())
  File "/usr/local/lib/python3.5/dist-packages/pip/__init__.py", line 233, in main
    return command.main(cmd_args)
  File "/usr/local/lib/python3.5/dist-packages/pip/basecommand.py", line 251, in main
    timeout=min(5, options.timeout)) as session:
  File "/usr/local/lib/python3.5/dist-packages/pip/basecommand.py", line 69, in _build_session
    if options.cache_dir else None
  File "/usr/lib/python3.5/posixpath.py", line 89, in join
    genericpath._check_arg_types('join', a, *p)
  File "/usr/lib/python3.5/genericpath.py", line 143, in _check_arg_types
    (funcname, s.__class__.__name__)) from None
TypeError: join() argument must be str or bytes, not 'int'

[pradyunsg]

I think it'll be better to put in effort to switch to a better format for the configuration -- #3809.

That said, if someone puts up a PR for this, I'll be happy to review it. :)

[pradyunsg]

I've labelled this issue as an "deferred PR".

This label is essentially for indicating that further discussion related to this issue should be deferred until someone comes around to make a PR. This does not mean that the said PR would be accepted - it has not been determined whether this is a useful change to pip and that decision has been deferred until the PR is made.

[pradyunsg]

#7735 is a PR attempting to fix this.

[pradyunsg]

FWIW, I do think we should fix this -- sharp edges that cut me in a PC case aren't fun when I'm working with it, and even though I'll learn to avoid those edges; it doesn't mean I don't have to consider them when working in the same PC case later.

But, as @pfmoore noted in #7736, the main concerns here are:

• complexity of implementation
• proper transition plan for users, to minimize the disruption for end users.

---

To minimize implementation complexity, I think all the special handling should be done in a post-processing step, as a new self-contained method added to ConfigOptionParser, that is called just before returning in ConfigOptionParser.get_default_values.

I think we may be able to make the transition work, with the new --unstable-feature option serving as the tool for transition:

• in pip YY.N:

  • Add a --unstable-feature better-negative-configuration-options
  • When that unstable feature is enabled, have nicer values / more consistency in how we handle configuration options in general.

• in pip YY.N (or pip YY.N+1)

  • Print an easily-silenced "Hey, this is changing in the future, try that out and let us know if you like the new behavior", printed when users are setting the options whose behavior would change under the newer mechanism.

• in pip YY.N+2 (or pip YY.N+3)

  • Switch to newer, nicer behavior
  • Drop --unstable-feature better-negative-configuration-options (error out on use)

[pradyunsg]

Thinking about this a bit more, it actually makes more sense to fix this as part of a broader transition (eg: to new configuration file format, new option parsing mechanism etc), since that transition would also follow a similar (if not the same) "transition plan", with additional benefits for both users and maintainers.

[pfmoore]

it actually makes more sense to fix this as part of a broader transition

+1 IMO changes in this area will be sufficiently disruptive (they directly affect user's experience with pip) that we should do as much as we can in one single change. As a result, I take the view that we should treat this as an unfortunate wart with our optparse-based command line handling (which we know we want to change at some point) and fix it at the same time as we switch away from that implementation.

[twhittock-disguise]

It seems some (as yet unknown) nvidia AI tools are setting the no-cache-dir option globally, effectively disabling caching for everyone on a system. Since it's done silently by installing some tools, it's difficult to detect. When an attempt is made to fix caching locally, it is not possible due to this bug.

Is it possible to add some mechanism to remove an option rather than setting its value? For example a new 'undefined' option for true/false options which removes the argument completely from the option parser. It seems unlikely that a new config file format is going to be rolled out since it's been the status since 2020...

The current workaround is to audit pip caching semi-regularly, and if it is suddenly disabled then pip config debug should tell the user which line to delete in the global config.

Clearly this is a problem with the tool installers which are so rudely altering the global config, but some workaround for local environments would be a real blessing.

[pradyunsg]

Is it possible to add some mechanism to remove an option rather than setting its value?

@twhittock-disguise We do have pip config unset <section>.<option> that you can run instead of relying on doing that work manually.

Also... FYI @warsaw who might want to know about this friction around Python packaging on their stuff.