A school-district automation team maintains shared Python modules used by several campus scripts. Installs from the public PyPI index keep failing authentication for those private modules. What should the team configure?

School-district automation commonly depends on internal Python libraries that encode campus-specific integrations and shared helpers. Those artifacts must not be published to the public Python Package Index, and installs that only hit public PyPI will fail authentication or never find the packages. The correct approach is to host the district’s internal modules on an authenticated private package feed (or private index/registry) and configure pip, poetry, or CI install steps to use that feed with scoped credentials while still reaching public indexes for open-source dependencies. That pattern preserves access control, auditability, and reproducible version pins for every campus script that imports the shared code.

A public PyPI mirror that merely caches laptop site-packages folders does not solve authentication for private modules; mirrors of public content still lack the district’s proprietary packages and can encourage insecure local sprawl. A Dockerfile that curls wheels while ignoring package indexes bypasses dependency resolution, integrity checks, and credentialed feeds, producing brittle, hard-to-update images. Floating git submodule URLs cloned at runtime without authentication are neither a package-management substitute nor an access-control model—they add nondeterministic fetches and leave internal code reachable without proper auth.

Exam caveat: private feeds complement, rather than replace, public indexes; candidates should not assume all dependencies move private. Operational check: from a clean CI runner, install a private module with the configured index URL and token, confirm the resolved version matches the pin, and verify that unauthenticated requests are rejected.