devpi may be the packaging infrastructure component to integrate with / document? search("docker devpi")

> index inheritance: Each index can inherit packages from another index, including the pypi cacheroot/pypi. This allows to have development indexes that also contain all releases from a production index. All privately uploaded packages will by default inhibit lookups from pypi, allowing to stay safe from an attacker who could otherwise upload malicious release files to the public PyPI index.

On Aug 31, 2015 8:33 AM, "Nick Coghlan" <ncoghlan@gmail.com> wrote:

On 31 August 2015 at 20:59, Wichert Akkerman <wichert@wiggy.net> wrote:
> Sure. My knowledge of rpm is 20 years out of date, so I am going to focus
> the deb/dpkg/apt world only.

Status Quo:

* Default: [pypi, ]

Proposed in the PEP (IIUC):

* Default: []

Suggested here:

For the purposes of this discussion, we can consider the two
ecosystems essentially equivalent. There are differences around what's
builtin and what's a plugin, but the general principles are the same:

* default repos are defined by each distro, not by the tool developers
* source repos and binary repos are separate from each other
* users can add additional repos of both kinds via config files
* config files can also set relative priorities between repos

That last one is the main defence against malicious repos - if you set
your distro repos to a high priority, then third party repos can't
override distro packages, but if you set a particular third party repo
to a high priority then it can override *anything*, not just the
packages you're expecting it to replace.

How do I diff these (ordered) graph solutions (w/ versions, extras_requires, and potentially _ABI_feat_x_)?

There are defined graph algorithms for JSON-LD (RDFa),

which would make it much easier to correlate

a version+[sdist,bdist,wheel-<...>] of

a package with a URI

with a package catalog with a URI

served by a repo with a URI

The key *differences* that are relevant to the current discussion are:

* PyPA are the maintainers of both the default repo *and* the installation tools
* we don't currently have any kind of repo priority mechanism

Is it traversed in a list,

or does config parser OrderedDict?

This is why I think it's important to be clear that we *want* to
improve the off-PyPI hosting experience, as that's something we
consider reasonable for people to want to do, but it's going to take
time and development effort. The question is thus whether it makes
sense to delay significant improvements for the common case (i.e.
hosting on PyPI), while we work on handling the minority case, and I
don't believe it does.

It *may* be worth hacking in special case handling for the packages
already hosted externally, but we can do that as exactly that (i.e. a
special case providing a legacy bridging mechanism until a better
solution is available), rather than as an indefinitely supported
feature.

Is there like a bigquery githubarchive of these,

for large queries?

Regards,
Nick.

--
Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
_______________________________________________
Distutils-SIG maillist - Distutils-SIG@python.org
https://mail.python.org/mailman/listinfo/distutils-sig