PEP 541 Request: opentelemetry-instrumentation-aiohttp-server

[lzchen]

Project to be claimed

PROJECT_NAME: https://pypi.org/project/opentelemetry-instrumentation-aiohttp-server

Your PyPI username

USER_NAME: https://pypi.org/user/opentelemetry

Reasons for the request

Attempting to upload to Pypi returns an error (see below) but hitting the project link above returns a 404, indicating it shouldn't exist. opentelemetry-instrumentation-aiohttp-server most likely exists but no version is released for it. I believe it was most likely due to some release error on our part such that attempting to release an actual version gives permission errors.

Maintenance or replacement?

Replacement

Source code repositories URLs

https://github.com/open-telemetry/opentelemetry-python-contrib/tree/main/instrumentation/opentelemetry-instrumentation-aiohttp-server

The hypothesis is that there is no "current project" other than this one. It was simply created but an error occurred during releasing of a version. Also perhaps there was someone who published a package with the same name before but deleted the only version.

Contact and additional research

The project was able to be uploaded to testpypi but continuously fails for Pypi. See https://github.com/pypi/warehouse/issues/14891. Attempting to upload a new version returns:

ERROR    HTTPError: 403 Forbidden from https://upload.pypi.org/legacy/
         The user 'opentelemetry' isn't allowed to upload to project 'opentelemetry-instrumentation-aiohttp-server'. See
         https://pypi.org/help/#project-name for more information.

Code of Conduct

• [X] I agree to follow the PSF Code of Conduct

[aabmass]

Can someone please take a look? This has been open for about 3 months now

[naisanzaa]

+1

[sbor23]

Would be quite amazing if someone could take this on after 4 months. This package is part of a bigger "meta" package and currently breaks a lot of users.

[decko]

+1

[robert-c-ewing]

This would be great to see resolved.

There's very little reason to leave this in its current state (it's entirely broken!) and it's in a namespace where having any other owner would be very confusing.

[viniciusd]

Is there someone we can ping here?

I've taken a look at the last support issues closed, none heard back from pypi

Edit

Ok, it seems PEP 541 requests are very low priority for the PSF and they have been piling up for a year or so https://discuss.python.org/t/is-pep-541-still-the-correct-solution/27436/19

It doesn't seem we can expect this issue to be addressed in the short to the medium term

[sbor23]

@viniciusd interesting link, thanks. That shines some light on the reality of lacking (paid) resources of many open source projects.

1. Security and Malware
2. Production incidents
3. Maintenance
4. Basic user-support
5. Account Recovery
6. 541/name requests

However I think this issue should not simply be on the bottom of the list, because it was most likely created by a bug on pypi.org server-side. As @lzchen said:

I believe it was most likely due to some release error on our part such that attempting to release an actual version gives permission errors.

So it's a bit disappointing that this is seen with the priority of a simple "I want to claim this package name because the previous owner was not reachable for x years" request.

But maybe I'm misunderstanding something here and I certainly don't want to blame any (unpaid) maintainer for this free service, hosting an open-source free package that I would like to use.

[robert-c-ewing]

However I think this issue should not simply be on the bottom of the list, because it was most likely created by a bug on pypi.org server-side. As @lzchen said:

I believe it was most likely due to some release error on our part such that attempting to release an actual version gives permission errors.

This informs my understanding of the situation as well -- this is a little more than a traditional 541.

[lzchen]

@sbor23

As @lzchen said: I believe it was most likely due to some release error on our part such that attempting to release an actual version gives > permission errors.

The initial diagnosis was found to not be true, it is simply a 541 case. With that being said, we have supplied a workaround that users can use if they would like to use the instrumentation in the meantime.

[tamirdavid1]

+1