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

Pip shouldn't use __main__.py in its warnings when invoked as a module #6576

Closed
webknjaz opened this issue Jun 5, 2019 · 15 comments
Closed
Labels
auto-locked Outdated issues that have been locked by automation project: <downstream> When the cause/effect is related to redistributors type: bug A confirmed bug or unintended behavior

Comments

@webknjaz
Copy link
Member

webknjaz commented Jun 5, 2019

Environment

  • pip version: 19.0.3
  • Python version: 3.7.3
  • OS: Fedora 30

Description

In its warning, Pip refers to mysterious __main__.py and I think that most of the entry-level users don't know what that is.
It would be more friendly to avoid using that name.

Expected behavior

WARNING: Running pip install with root privileges is generally not a good idea. Try `pip install --user` instead.

or (better)

WARNING: Running pip install with root privileges is generally not a good idea. Try `python3.7 -m pip install --user` instead.

How to Reproduce

sudo python -m pip install {{ pkg }}

Output

[root@4aab71e5d9d1 /]# python3.7 -m pip install epdb
WARNING: Running pip install with root privileges is generally not a good idea. Try `__main__.py install --user` instead.
...
@triage-new-issues triage-new-issues bot added the S: needs triage Issues/PRs that need to be triaged label Jun 5, 2019
@webknjaz webknjaz changed the title Pip shouldn't use __main__.py in its warnings Pip shouldn't use __main__.py in its warnings when invoked as a module Jun 5, 2019
@pradyunsg pradyunsg added type: bug A confirmed bug or unintended behavior project: <downstream> When the cause/effect is related to redistributors and removed S: needs triage Issues/PRs that need to be triaged labels Jun 7, 2019
@pradyunsg
Copy link
Member

Hmm, I don't think that's vanilla pip.

@torsava @stratakis @hroncok Is this a patch applied by Fedora?

@hroncok
Copy link
Contributor

hroncok commented Jun 7, 2019

@hroncok
Copy link
Contributor

hroncok commented Jun 7, 2019

It's the sys.argv[0] value that isn't very good in this case. If you know how to get the actual command line invocation, that would be great. Of course, we could detect __main__ and replace it with sys.executable -m pip.

@hroncok
Copy link
Contributor

hroncok commented Jun 7, 2019

@pradyunsg do you mind if we finish this conversation here?

@hroncok
Copy link
Contributor

hroncok commented Jun 7, 2019

Like this?

        # Check whether we have root privileges and aren't in venv/virtualenv
        if os.getuid() == 0 and not is_venv():
            command = path.basename(sys.argv[0])
            if command == "__main__.py":
                command = path.basename(sys.executable) + " -m pip"
            logger.warning(
                "WARNING: Running pip install with root privileges is "
                "generally not a good idea. Try `%s install --user` instead."
                % command
            )

@webknjaz
Copy link
Member Author

webknjaz commented Jun 7, 2019

@hroncok getting the real (full) command line in Python is PITA and needs a lot of hacks.
Here's what I did a while back: https://github.com/cherrypy/cherrypy/blob/862a7d7/cherrypy/process/wspbus.py#L382-L511 (this could be extended by adding extra fallback looking at /proc/{{ PID }}/cmdline).

I've been meaning to release a dist with that to PyPI but never got to do it...

@webknjaz
Copy link
Member Author

webknjaz commented Jun 7, 2019

Also, you can think about something like this:
asciicast

@pradyunsg
Copy link
Member

@pradyunsg do you mind if we finish this conversation here?

Nope. :)

@pradyunsg
Copy link
Member

pradyunsg commented Jun 7, 2019

@webknjaz Please do close this once this is resolved. :)

(or @ me since I'm unsubscribing for now)

@webknjaz
Copy link
Member Author

webknjaz commented Jun 7, 2019

I'm okay with closing it right away if @hroncok has a better place for tracking it. I just wanted to report it upstream but it doesn't actually affect me :)

@hroncok
Copy link
Contributor

hroncok commented Jun 7, 2019

I'll do a PR in Fedora and post a link here. Unfortunately I won't get to it before Monday.

@hroncok
Copy link
Contributor

hroncok commented Jun 10, 2019

@webknjaz
Copy link
Member Author

@hroncok should I keep this open?

@hroncok
Copy link
Contributor

hroncok commented Jun 10, 2019

Whatever you prefer.

@webknjaz
Copy link
Member Author

Okay, closing then.

@lock lock bot added the auto-locked Outdated issues that have been locked by automation label Jul 10, 2019
@lock lock bot locked as resolved and limited conversation to collaborators Jul 10, 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 project: <downstream> When the cause/effect is related to redistributors type: bug A confirmed bug or unintended behavior
Projects
None yet
Development

No branches or pull requests

3 participants