Content selector for pypi repository

post by teiva.labbe on Feb 6, 2019

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)

post by mmartz on Feb 6, 2019

I think you want something like

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

post by rseddon on Feb 6, 2019

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:

7 years later

post by roland.asmann on Sep 2, 2025

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?

post by mprescott on Sep 2, 2025

@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.

post by roland.asmann on Sep 3, 2025

@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.