Remove the pip --no-index advice from the PyPI registry docs

What does this MR do?

The PyPI package registry page tells readers who want packages installed only from GitLab to pass --no-index together with --index-url. That combination cannot work: --no-index makes pip ignore every package index, the one --index-url names included, so pip install fails with (from versions: none) even for a package the GitLab registry holds. The issue reports exactly that, and the flag's own help says it: "Ignore package index (only looking at --find-links URLs instead)."

This MR removes the advice from the five places it appears:

• doc/user/packages/pypi_repository/_index.md:
  • Package request forwarding security notice: the list keeps its first item, turn off package forwarding in your group settings. Its second item, which said to use --index-url and --no-index together, becomes two: set the GitLab registry URL with --index-url instead of --extra-index-url, and do not use --no-index, each with the reason. The prerequisites and steps for the group setting, and the link to the instance setting, follow as before.
  • Security implications: the either: list under --index-url collapses into "turn off package forwarding".
  • The best practices bullet in that section keeps --index-url and drops --no-index: it now says to use --index-url instead of --extra-index-url when installing private packages.
  • Troubleshooting > Unexpected package sources: the --no-index bullet now says to turn off package forwarding to prevent the fallback to PyPI, and a new bullet says to use --index-url instead of --extra-index-url, so that pip does not query PyPI directly.
• doc/user/packages/workflows/project_registry.md: the PyPI tab of Configure a top-level group endpoint drops --no-index from its pip install example. The example's lead-in read "Or use environment variables:" above a command that sets none, so it now reads "Or pass the index URL to pip install:".

The Japanese translations under doc-locale/ja-jp/ carry the same advice; they follow the English pages through the translation automation, so this MR changes the English source only.

The half of the old advice that holds is --index-url, and the page keeps it. Two things keep a package off pypi.org, and each does one half: turning off package forwarding keeps pip from receiving packages from pypi.org through the GitLab index, which is also where the issue ends up, and --index-url instead of --extra-index-url keeps pip from asking pypi.org itself. The page already explains how to turn off forwarding, for a group and for the instance, so this MR adds no new procedure.

How I checked it

In python:3.13-slim with pip 26.2.1, using dry runs against the PyPI endpoints of the public gitlab-org/security-products/analyzers/api-fuzzing project (19617580) and of the gitlab-org group (9970) on GitLab.com, read without credentials, on 2026-10-10.

A package the registry holds installs through --index-url alone and is not found once --no-index is added:

$ pip install --dry-run --no-deps --index-url https://gitlab.com/api/v4/projects/19617580/packages/pypi/simple gitlab-apifuzzing-cli
Looking in indexes: https://gitlab.com/api/v4/projects/19617580/packages/pypi/simple
Collecting gitlab-apifuzzing-cli
  Downloading gitlab_apifuzzing_cli-1.6.151-py2.py3-none-any.whl (5.0 kB)
Would install gitlab-apifuzzing-cli-1.6.151
exit status: 0

$ pip install --dry-run --no-deps --index-url https://gitlab.com/api/v4/projects/19617580/packages/pypi/simple --no-index gitlab-apifuzzing-cli
ERROR: Could not find a version that satisfies the requirement gitlab-apifuzzing-cli (from versions: none)
ERROR: No matching distribution found for gitlab-apifuzzing-cli
exit status: 1

With -v, the --no-index run never prints a Looking in indexes: line. The same happens with pypi.org as the only index (six resolves without --no-index, and is not found with it), so this is pip, not the GitLab endpoint.

The group registry example from project_registry.md, as master has it and as this branch has it:

$ pip install --dry-run --no-deps --index-url https://gitlab.com/api/v4/groups/9970/-/packages/pypi/simple/ --no-index gitlab-apifuzzing-cli
ERROR: Could not find a version that satisfies the requirement gitlab-apifuzzing-cli (from versions: none)
ERROR: No matching distribution found for gitlab-apifuzzing-cli
exit status: 1

$ pip install --dry-run --no-deps --index-url https://gitlab.com/api/v4/groups/9970/-/packages/pypi/simple/ gitlab-apifuzzing-cli
Looking in indexes: https://gitlab.com/api/v4/groups/9970/-/packages/pypi/simple/
Collecting gitlab-apifuzzing-cli
  Downloading gitlab_apifuzzing_cli-1.6.151-py2.py3-none-any.whl (5.0 kB)
Would install gitlab-apifuzzing-cli-1.6.151
exit status: 0

And the behavior the page warns about, which package forwarding controls: a package the project does not hold, asked for through the project's index alone, comes from PyPI through the forward endpoint:

$ pip install --dry-run --no-deps --index-url https://gitlab.com/api/v4/projects/19617580/packages/pypi/simple -v six
Looking in indexes: https://gitlab.com/api/v4/projects/19617580/packages/pypi/simple
Collecting six
  Obtaining dependency information for six from https://gitlab.com/api/v4/projects/19617580/packages/pypi/forward/six/files.pythonhosted.org/packages/b7/ce/149a00dd41f10bc29e5921b496af8b574d8413afcd5e30dfa0ed46c2cc5e/six-1.17.0-py2.py3-none-any.whl.metadata
  Downloading six-1.17.0-py2.py3-none-any.whl.metadata (1.7 kB)
Would install six-1.17.0
exit status: 0

And why the page still names --index-url: with the GitLab registry passed as --extra-index-url, pip keeps pypi.org as an index of its own, so it asks pypi.org directly whatever the forwarding setting is:

$ pip install --dry-run --no-deps --extra-index-url https://gitlab.com/api/v4/projects/19617580/packages/pypi/simple -v six
Looking in indexes: https://pypi.org/simple, https://gitlab.com/api/v4/projects/19617580/packages/pypi/simple
Collecting six
  Obtaining dependency information for six from https://gitlab.com/api/v4/projects/19617580/packages/pypi/forward/six/files.pythonhosted.org/packages/b7/ce/149a00dd41f10bc29e5921b496af8b574d8413afcd5e30dfa0ed46c2cc5e/six-1.17.0-py2.py3-none-any.whl.metadata
  Downloading six-1.17.0-py2.py3-none-any.whl.metadata (1.7 kB)
Would install six-1.17.0
exit status: 0

Lint

• scripts/lint-doc.sh on both pages, in the lint image the docs-lint markdown job uses (markdownlint-cli2 0.23.2, Vale 3.21.0): passed, with no markdownlint issues and no Vale errors, warnings or suggestions at its level.
• Vale at suggestion level on this branch and on master: the same nine findings on both; only their line numbers and the two reading-level scores (7.65 to 7.64, 8.92 to 8.86) changed, so this MR adds none.
• lychee --offline --no-progress --include-fragments on both pages, as the docs-lint links job runs it: 0 errors.
• Both commit messages pass scripts/lint/commit_linter.rb and the Danger commit linter (gitlab-dangerfiles 4.12.0).

Related issues

Closes #582311 (closed)

Author's checklist

• Optional. Consider taking the GitLab Technical Writing Fundamentals course.
• Follow the:
  • Documentation process.
  • Documentation guidelines.
  • Style Guide.
• If you're adding a new page, add the product availability details under the H1 topic title.
• If you are a GitLab team member, request a review based on:
  • The documentation page's metadata.
  • The associated Technical Writer.

If you are a GitLab team member and only adding documentation, do not add any of the following labels:

• ~"frontend"
• ~"backend"
• ~"type::bug"
• ~"database"

These labels cause the MR to be added to code verification QA issues.

Reviewer's checklist

Documentation-related MRs should be reviewed by a Technical Writer for a non-blocking review, based on Documentation Guidelines and the Style Guide.

If you aren't sure which tech writer to ask, use roulette or ask in the #docs Slack channel.

• If the content requires it, ensure the information is reviewed by a subject matter expert.
• Technical writer review items:
  • Ensure docs metadata is present and up-to-date.
  • Ensure the appropriate labels are added to this MR.
  • Ensure a release milestone is set.
  • If relevant to this MR, ensure content topic type principles are in use, including:
    • The headings should be something you'd do a Google search for. Instead of Default behavior, say something like Default behavior when you close an issue.
    • The headings (other than the page title) should be active. Instead of Configuring GDK, say something like Configure GDK.
    • Any task steps should be written as a numbered list.
    • If the content still needs to be edited for topic types, you can create a follow-up issue with the docs-technical-debt label.
• Review by assigned maintainer, who can always request/require the reviews above. Maintainer's review can occur before or after a technical writer review.