devpi-dev

Download

devpi-dev@python.org

January 2015

3 participants
2 discussions

per package permissions
by Kevin Patterson 28 Jan '15

28 Jan '15

Is it be possible to somehow interject per package permissions control (within a single index) in to the current devpi setup? or is the only way to do that via a development index per package? Even if it is a combo of both "auth_user" and "on_upload" hook that I would need to write...is it doable? If not, I'm curious what is perhaps the most number of indexes folks have used? I'm pretty sure I would be hitting in to the hundreds (but probably not thousands). Thanks, Kevin

2 2

Filtering packages that can be mirrored from PyPI
by Matěj Stuchlík 28 Jan '15

28 Jan '15

Hi, below is the UI draft for the feature proposed in [0]: We propose a new feature that would allow users to specify "package filter" for indexes. That way one can narrow down the set of packages that should be mirrored. See [0] for motivation and some more details. Setting filter ============== > devpi index <index_name> filter=<package_filter> The client parses the <package_filter> file to make sure it comforms with the specification (See 'Package filter syntax' below). If the syntax is correct, it pushes it to the devpi server, where it is saved as property of the given index and, if necessary, packages that are already mirrored but shouldn't be are deleted. The filter keyword option can be used either during creation of an index, or by itself, to modify an existing index, e.g. > devpi index -c <index_name> filter=<package_filter> and > devpi index <index_name> filter=<package_filter> The filtering can be turned off by giving no value to the filter keyword [1], e.g. > devpi index <index_name> filter= Viewing filter [2] ============== > devpi index <user>/<index_name> Also lists an URL of the package filter file as pushed to the server [3] Package filter syntax ===================== A file containing on each line a package name (and optionally version specification compatible with PEP 440) that ARE allowed to be mirrored. If the version specification part is ommited, all versions of given package are allowed. Lines begining with Lines begining with # are considered comments and are not processed. Example package filter file: six # django <1.6 isn't mirrored because foo django>=1.6 django-debug-toolbar==1.2.3 [0] https://bitbucket.org/hpk42/devpi/issue/198/whitelisting-packages-that-can-… [1] Alternatively perhpaps by pointing it to an empty file? [2] I'm quite unsure with this section, would appreciate a comment. [3] I figured it would be better to give the URL instead of straigth up listing the packages, since: a) The filter could contain several hundered packages b) This way it seems simpler to modify the filter (wget > vim > push) Let me know if I've missed something. :) Cheers, Matt

1 0