PyPi_Namespace_PEP

PEP: 9999
Title: Sample reStructuredText PEP Template
Author: Dave Ashby
Status: Draft
Type: Informational
Content-Type: text/x-rst
Created: 06-May-2019
Post-History: 


Abstract
========

This PEP proposes the addition of namespace functionality in PyPi. As
PEP 20 notes: 

    “Namespaces are one honking great idea -- let’s do more of those”.

But at the moment, PyPi itself uses a flat, "global" namespace. This
PEP proposes to change that model, maintaining the global namespace
but optionally supporting local namespaces.

The source for this (or any) PEP can be found in the PEPs repository,
viewable on the web at https://github.com/python/peps/ .


Rationale
=========

Recently PyPA has undertaken a number of efforts to improve security
and functionality provided by PyPi. This PEP continues that theme by
introducing namespaces. Namespaces provide a foundation for future
incremental improvements, such as allowing namespace owners to "opt
in" to new features. 

Additionally, namespaces allow package consumers to have clarity on
which group is maintaining a given package.

Finally, by managing the namespaces in a controlled fashion we can
largely mitigate the threat associated with typosquatting attacks.


Background
==========

In September 2017, security researchers identified a number of
malicious packages uploaded to PyPi that were typosquatting [1]_. The
corresponding bug on python.org despaired of any obvious fix for
typosquatting [2]_. Given a global namespace, typosquatting is certainly
a non-trivial problem to solve. Support for local namespaces makes
defeat of typosquatting attacks a much more tractable problem.

Analysis of the "top 5000" packages downloaded from PyPi by the PEP
author also highlighted the somewhat scary state of affairs with
Python package naming, as there are many inactive packages that could
easily be confused for packages provided by major providers (e.g. the
`aws` package was developed by a community member, has no affiliation
with Amazon Web Services, and hasn't been updated in many years).


Technical Considerations
========================

A primary implementation consideration is around how best to delimit
namespaces. Potential options include a dot-delimiter
(namespace.packagename), a slash delimiter (namespace/packagename), or
other TBD syntax. This is a implementation consideration that will
benefit from feedback from across the python ecosystem, as it could
have implications to how package dependencies are specified.

Another consideration is around whether multiple layers of namespaces
should be supported. This PEP initially targets a single-layer
namespace model, but this model could be extended to support multiple
layers if use-cases drive us in that direction.

Finally, another potential concern is how best to handle backwards-
compatibility for projects that choose to make use of the namespace
functionality. Ideally, project owners would be able to configure
redirects to the new project location along with issuing a
informational or warning message advising the user of the new project
location.


Process Considerations
======================

The NuGet community has adopted a process for "ID prefix
reservations" [3]_ (their version of namespaces) that could potentially be
emulated by PyPA. Their process addresses mechanisms for how
namespaces are requested, approved, challenged, and revoked. PEP 541 [4]_
also provides a framework that could be extended to accomodate
namespaces.





References and Footnotes
========================

.. [1] "[Security-announce] Typo squatting and malicious packages on PyPI", Stinner,(https://mail.python.org/pipermail/security-announce/2017-September/000000.html)
.. [2] "Security Issue: Typosquatting", (https://bugs.python.org/issue27339)
.. [3] ID prefix reservations, (https://docs.microsoft.com/en-us/nuget/reference/id-prefix-reservation)
.. [4] PEP 541, "Package Index Name Retention", Langa, (https://www.python.org/dev/peps/pep-0541/)


..
   Local Variables:
   mode: indented-text
   indent-tabs-mode: nil
   sentence-end-double-space: t
   fill-column: 70
   coding: utf-8
  
End