Skip to content

Commit c4ec646

Browse files
43834383
committed
PEP 582: (First draft) Using namespace on projects packages
1 parent 5c7c89c commit c4ec646

File tree

2 files changed

+278
-0
lines changed

2 files changed

+278
-0
lines changed

‎pep-0582.rst

Lines changed: 123 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,123 @@
1+
PEP: 582
2+
Title: Manage packages on repositories with namespaces
3+
Version: $Revision$
4+
Last-Modified: $Date$
5+
Author: Hervé Beraud <[email protected]>
6+
Status: Draft
7+
Type: Standards Track
8+
Content-Type: text/x-rst
9+
Created: 25-Jun-2018
10+
Python-Version: 3.8
11+
12+
13+
Abstract
14+
========
15+
16+
This PEP outlines some functionalities to introduce on python packages
17+
management and best practices to allow a more flexible approach to work
18+
on forked project and to reduce security risks with packages repositories and
19+
dependencies requirements.
20+
21+
This PEP will be introducing namespace on projects naming for allow user to
22+
work on forks and testing package deployment and installation.
23+
24+
Also namespace reduce the risk that users deal with a
25+
miscellaneous package come from a typo squatting.
26+
27+
28+
Motivation
29+
==========
30+
31+
Currently When a project is already register on pypi it's not possible
32+
to users to test a fork of any projects with the same name when
33+
it's already exist, on pypi.org and on test.pypi.org the problem is the same.
34+
35+
Manage projects by namespace increase possiblities for the python community.
36+
37+
With this feature we can introduce trusted packages by allow install/search
38+
without namespace and add namespaces on untrusted packages like the
39+
docker behavior (`docker pull nginx` or `docker pull 4383/nginx`).
40+
41+
Also, project namespace and trusted packages help us to reduce some
42+
security risks, like typo squatting (example_, `pypa github discussion`_).
43+
44+
.. _example: http://www.nbu.gov.sk/skcsirt-sa-20170909-pypi/index.html
45+
.. _pypa_github_discussion: https://github.com/pypa/pypi-legacy/issues/644
46+
47+
48+
Rationale
49+
=========
50+
51+
With this feature we can introduce trusted packages by allow install/search
52+
without namespace and add namespaces on untrusted packages like the
53+
docker command behavior (`docker pull nginx` or `docker pull 4383/nginx`).
54+
55+
56+
How to work docker command?
57+
---------------------------
58+
59+
On docker a trusted package is package maintained by the docker team himeself.
60+
Namespace does not exist when the package is maintained by the docker team.
61+
When a package is maintain by a third user namespace appear into the name.
62+
63+
64+
How to work inside the python community?
65+
----------------------------------------
66+
67+
The goal of this PEP is not to delegate the trusted projects maintainance
68+
to the pypa team or to a specific python contributor team. Projects rest
69+
owned and maintained by their original teams.
70+
71+
This PEP propose to create a specific repository on github to manage/elect
72+
trusted projects. The repository need to be hosted under the
73+
pypa organisation and can be named `pypa/trusted`.
74+
75+
76+
How to define the namespace?
77+
----------------------------
78+
79+
By default the used namespace is the username of the pypa account.
80+
81+
82+
What's the impact on the python ecosystem?
83+
------------------------------------------
84+
85+
- Warehouse need to be updated to deal with namespaces and need to store this
86+
information and need to allow to change this information by call API for allow
87+
the voting system defined by PEP-582 to update this information when a package
88+
is move to trusted.
89+
- pip need to be updated to deal with namespaces
90+
- generated packages need to contains package namespace informations when we
91+
use `pip show <package_name>` to allow upgrade of old packages
92+
- pip and others packages managers need to manage site-packages with namespaces
93+
to allow projects with same name to coexist together.
94+
- PEP-583 and the trusted packages mechanism avoid the fact that third
95+
party projects need to update their dependencies once dependencies have been
96+
declared trusted.
97+
98+
99+
Benefits
100+
========
101+
102+
- Improve project trust
103+
- Improve package trusting and reduce the risk that users deal with
104+
a miscellaneous package
105+
- Allow users to provide forked version of an official project
106+
- Allow users to test that packaging work fine on pypi
107+
108+
109+
Copyright
110+
=========
111+
112+
This document has been placed in the public domain.
113+
114+
115+
116+
..
117+
Local Variables:
118+
mode: indented-text
119+
indent-tabs-mode: nil
120+
sentence-end-double-space: t
121+
fill-column: 70
122+
coding: utf-8
123+
End:

‎pep-0583.rst

Lines changed: 155 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,155 @@
1+
PEP: 583
2+
Title: Vote for trusted packages
3+
Version: $Revision$
4+
Last-Modified: $Date$
5+
Author: Hervé Beraud <[email protected]>
6+
Status: Draft
7+
Type: Standards Track
8+
Content-Type: text/x-rst
9+
Created: 25-Jun-2018
10+
Python-Version: 3.8
11+
12+
13+
Abstract
14+
========
15+
16+
This PEP outlines the voting mechanism to define trusted packages.
17+
It's the continuity of the PEP-582 and it's the methodoly part of the set
18+
of the functionality defined for the new behavior of the package management.
19+
20+
21+
Motivation
22+
==========
23+
24+
Packages namespaces introduced by the PEP-582 need to define a voting
25+
system to remove namespaces on mainstream packages or on none forked
26+
packages.
27+
28+
With this feature we can introduce trusted packages by allow install/search
29+
without namespace and add namespaces on untrusted packages like the
30+
docker behavior (`docker pull nginx` or `docker pull 4383/nginx`).
31+
32+
Also, project namespace and trusted packages help us to reduce some
33+
security risks, like typo squatting (example_, `pypa github discussion`_).
34+
35+
.. _example: http://www.nbu.gov.sk/skcsirt-sa-20170909-pypi/index.html
36+
.. _pypa_github_discussion: https://github.com/pypa/pypi-legacy/issues/644
37+
38+
39+
Rationale
40+
=========
41+
42+
With this mechanism we can introduce trusted packages by allowing
43+
install/search without namespace and add namespaces on untrusted packages like
44+
the docker command behavior (`docker pull nginx` or `docker pull 4383/nginx`).
45+
46+
47+
How to work docker command?
48+
---------------------------
49+
50+
On docker a trusted package is package maintained by the docker team himeself.
51+
Namespace does not exist when the package is maintained by the docker team.
52+
When a package is maintain by a third user namespace appear into the name.
53+
54+
55+
How to work inside the python community?
56+
----------------------------------------
57+
58+
The goal of this PEP is not to delegate the trusted projects maintainance
59+
to the pypa team or to a specific python contributor team. Projects rest
60+
owned and maintained by their original teams.
61+
62+
This PEP propose to create a specific repository on github to manage/elect
63+
trusted projects. The repository need to be hosted under the
64+
pypa organisation and can be named `pypa/trusted`.
65+
66+
67+
How to define the namespace?
68+
----------------------------
69+
70+
By default the used namespace is the username of the pypa account.
71+
72+
73+
how to define if a project is trusted?
74+
--------------------------------------
75+
76+
Projects can being trusted by sending a pull request on the `pypa/trusted`
77+
repository.
78+
79+
A pull request need to be a formalized file where projects teams can define
80+
a project owning.
81+
82+
A unique pull request by project need to send and a robot can check if the
83+
project was already trusted to reduce boring tasks.
84+
85+
A review must be realized on these pull requests and if the pypa team decide to
86+
accept the project become automaticaly trusted.
87+
88+
Merge a pull request allow Pypa to remove the namespace automaticaly.
89+
To define if a project is trusted project the maintainers need to send
90+
a formalized pull request to the `pypa/trusted` repository.
91+
92+
Reviewer accept or reject the pull request. We can require a minimum number of
93+
review to ensure that is a really trusted package.
94+
95+
96+
How to standardize informations sended with the pull request?
97+
-------------------------------------------------------------
98+
99+
Like PEPs repository, `pypa/trusted` must contains a file by project who ask
100+
to become trusted.
101+
102+
Each files must be named with the same name of the project without prefixed
103+
by the namespace. The mechanisme avoid two person to ask the same name for
104+
two different projects (forks use case...).
105+
106+
Each files must contains the following information in yaml format (by example):
107+
- name: the project name
108+
- namespace: the project namespace
109+
- author_email: the email of the author to be sure that correspond
110+
to package informations.
111+
112+
113+
How reviewers must validate pull requests?
114+
------------------------------------------
115+
116+
Each reviewer need to verify that informations correspond to the original
117+
project maintainer (none forked project), that project is not a typo squatting
118+
(cf. requests/request).
119+
120+
121+
What's the impact on the python ecosystem?
122+
------------------------------------------
123+
124+
- Warehouse need to be updated to deal with namespaces
125+
- pip need to be updated to deal with namespaces
126+
127+
I don't think that distutils or setuptools are impacted by this.
128+
129+
130+
Benefits
131+
========
132+
133+
- Improve project trust
134+
- Improve package trusting and reduce the risk that users deal with
135+
a miscellaneous package
136+
- Allow users to provide forked version of an official project
137+
- Allow users to test that packaging work fine on pypi
138+
139+
140+
Copyright
141+
=========
142+
143+
This document has been placed in the public domain.
144+
145+
146+
147+
..
148+
Local Variables:
149+
mode: indented-text
150+
indent-tabs-mode: nil
151+
sentence-end-double-space: t
152+
fill-column: 70
153+
coding: utf-8
154+
End:
155+

0 commit comments

Comments
 (0)