Content selector for pypi repository

Sonatype Nexus Repository
1

Hello everyone,

I have created two pypi repository in nexus (for snapshot and release version) but nexus don’t accept version policy for pypi.

But snapshot version of pipy artifacts have “.dev” pattern in their name.

So I have created “content selectors” for the pypi artifacts (to prohibit to push in release repository artifacts with “.dev” pattern and only allow these one in snapshot repository)

The content selectors are:

  • format == “pypi” and path = ~ “(?! ^.dev.).*” (exclude “.dev” pattern)

  • format == “pypi” and path = ~ “.dev.” (Allow only “.dev” pattern)

(The preview result for the content selctors are good)

Unfortunately that doesn’t work!

I cannot push “.dev” pattern in snapshot repository, but the ban for release repository work.

Do you have an idea to fix that ?

Thanks

Nexus Version: OSS 3.15.2-01
Debian Version: Debian GNU/Linux 9.5 (stretch)

2

I think you want something like

format == "pypi" and path =~ ".*(\.dev)$"
3

In PyPi repository format an upload is done via a POST request to the root of the repository. Unfortunately, this means there isn’t any way to create a content selector in Nexus for uploads for this format. We have an issue open here for this:

5

It’s been a couple of years, the referenced issue is not available anymore (because of the server not being available anymore) and I am trying to setup my nexus with content selectors, so I wanted to know what the current status on this is? Has it been implemented and if so, how do I setup a content selector for uploading PyPi?

6

@roland.asmann This hasn’t been implemented. The PyPI protocol makes it a little tricky to do this in the case of writes, which is the most common use case for content selectors. Unlike most other package managers, which put their content to the eventual URL it should be served at, the pip client uses a POST of the binary and leaves the server to unzip the binary and figure out what it is. This means that the permission check isn’t something that works with the approach we’re using for every other ecosystem, and we haven’t had enough demand yet for this particular one to hop the queue.

7

@mprescott Seeing it was an issue 7 years ago, is it still something that is on the roadmap? I wonder why this isn’t more of an issue, we actually had to retroactively implement this for our other repository types.