Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

no-warn-script-location doesn't work in pip.conf when PIP_CONFIG_FILE is used #6209

Closed
chdiza opened this issue Jan 27, 2019 · 7 comments · Fixed by #6372
Closed

no-warn-script-location doesn't work in pip.conf when PIP_CONFIG_FILE is used #6209

chdiza opened this issue Jan 27, 2019 · 7 comments · Fixed by #6372
Labels
auto-locked Outdated issues that have been locked by automation C: cli Command line interface related things (optparse, option grouping etc) C: configuration Configuration management and loading good first issue A good item for first time contributors to work on type: docs Documentation related

Comments

@chdiza
Copy link

chdiza commented Jan 27, 2019

Environment

  • pip version: 19.0.1
  • Python version: 2.7.15
  • OS: macOS 10.14.3

Description

Pip appears to ignore the setting of no-warn-script-location if it's specified in pip.conf and pip.conf is in a nonstandard location (but should be read because of PIP_CONFIG_FILE pointing to it).

Expected behavior

pip install -U foo (where foo will install some executables) will install foo and there is no warning about how the newly installed exectuables aren't on my $PATH.

What actually happens is that I get the warning. Pip is ignoring this setting in my pip.conf.

Note that if I use the --no-warn-script-location flag directly on the cli, there is no warning.

How to Reproduce

  1. Make a custom python 2.7.15 but where the resulting python binaries aren't on $PATH. Rather, they're symlinked into a folder that is on $PATH. Install pip using said custom python.
  2. In my ~/.profile I have export PIP_CONFIG_FILE="~/somepath/pip.conf"
  3. In that pip.conf I have:
[install]
upgrade = true
no-warn-script-location = true
  1. Then run pip install virtualenv (e.g., the specific package doesn't seem to make a difference.)
  2. Observe that I still get a warning that I explicitly asked not to get.

Output

DEPRECATION: Python 2.7 will reach the end of its life on January 1st, 2020. Please upgrade your Python as Python 2.7 won't be maintained after that date. A future version of pip will drop support for Python 2.7.
Collecting virtualenv
  Using cached https://files.pythonhosted.org/packages/8f/f1/c0b069ca6cb44f9681715232e6d3d65c75866dd231c5e4a88e80a46634bb/virtualenv-16.3.0-py2.py3-none-any.whl
Requirement already satisfied, skipping upgrade: setuptools>=18.0.0 in /pathtocustompy/lib/python2.7/site-packages (from virtualenv) (40.7.0)
Installing collected packages: virtualenv
  The script virtualenv is installed in '/pathtocustompy/bin' which is not on PATH.
  Consider adding this directory to PATH or, if you prefer to suppress this warning, use --no-warn-script-location.
Successfully installed virtualenv-16.3.0
@cjerdonek cjerdonek added the C: configuration Configuration management and loading label Jan 27, 2019
@cjerdonek
Copy link
Member

cjerdonek commented Jan 28, 2019

Actually, this looks like it's another example of this: #5735 (or this #5200)
Does it work if you set the value to false?

Also see this section of the docs: https://pip.pypa.io/en/stable/user_guide/#config-file

To enable the boolean options --no-compile and --no-cache-dir, falsy values have to be used:

@chdiza
Copy link
Author

chdiza commented Jan 28, 2019

Does it work if you set the value to false?

I didn't try that (for obvious reasons), but will try it now when I get a chance.

I did try doing warn-script-location=no, but that didn't work.

@chdiza
Copy link
Author

chdiza commented Jan 28, 2019

Turns out, it does work. This is a funny bug! Are there plans to fix it?

@cjerdonek
Copy link
Member

cjerdonek commented Jan 28, 2019

Yeah, it is funny. :) It's not so easy to fix because it's baked in and so there are backwards compatibility considerations. Many people could be relying on the current interpretation of the values.

I will mark this as a documentation issue though because I think it can be documented better (e.g. mentioned in the CLI help string for the option and the affected options enumerated in the configuration section of the pip docs).

@cjerdonek cjerdonek added type: docs Documentation related C: cli Command line interface related things (optparse, option grouping etc) labels Jan 28, 2019
@pradyunsg
Copy link
Member

@cjerdonek Do you reckon this can be a place where a first time contributor can contribute?

@cjerdonek cjerdonek added the good first issue A good item for first time contributors to work on label Mar 10, 2019
@cjerdonek
Copy link
Member

cjerdonek commented Mar 10, 2019

@pradyunsg Yes, I think so.

@pradyunsg
Copy link
Member

This issue is a good starting point for anyone who wants to help out with pip's development -- it's simple and the process of fixing this should be a good introduction to pip's development workflow. See the discussion above to understand what the desired fix is.

kx-chen added a commit to kx-chen/pip that referenced this issue Apr 1, 2019
chrahunt pushed a commit to kx-chen/pip that referenced this issue Nov 11, 2019
@lock lock bot added the auto-locked Outdated issues that have been locked by automation label Dec 11, 2019
@lock lock bot locked as resolved and limited conversation to collaborators Dec 11, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
auto-locked Outdated issues that have been locked by automation C: cli Command line interface related things (optparse, option grouping etc) C: configuration Configuration management and loading good first issue A good item for first time contributors to work on type: docs Documentation related
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants