PCAP Modules and Packages Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✗

  sudo pip install mypackage

  Why it's wrong here

  Although sudo temporarily grants root privileges, it forces pip to write into the system-wide site-packages directory owned by root, bypassing the permission error but at the cost of system integrity. Worse, running pip under sudo executes arbitrary setup.py code from PyPI as the root user, creating a serious security vulnerability. Modern distributions also implement PEP 668, making system-wide pip installs extremely dangerous without a virtual environment, so this approach is strongly discouraged.

• ✓

  pip install --user mypackage

  Why this is correct

  This is correct because the --user flag makes pip install the package into the current user's private site-packages directory (e.g., ~/.local/lib/python3.x/site-packages), which is owned by that user and therefore requires no elevated permissions. It resolves the permission error without altering system Python packages, and the directory is automatically included in sys.path by default. This is a safe, supported way to install packages when you lack administrative rights, though virtual environments are often preferred for isolation.

• ✗

  pip install --ignore-installed mypackage

  Why it's wrong here

  The --ignore-installed flag tells pip to disregard any already installed versions of the package and force a fresh installation, but it has no effect on where pip attempts to write. If the system site-packages directory is not writable by your user, pip will still raise the same permission error when copying files there. This option is useful for resolving conflicts between installed versions or repairing a broken install, but it does not address the underlying directory-permission problem.

• ✗

  pip install --target mypackage

  Why it's wrong here

  The --target option requires a directory path argument, so the command as written is syntactically invalid: --target mypackage treats 'mypackage' as an output directory, causing a pip error. Even if you provided a valid path, this option only installs into that specific directory; if the path is outside your writable areas or is read-only, the permission error persists. It is designed for custom deployment locations (e.g., vendoring dependencies), not for solving system-permission issues, and you would also have to manually manage PYTHONPATH to use the installed package.

Go deeper

Related to this question