PyPI backend should allow defining a custom package name

[akien-mga]

Currently the PyPI backend can only check https://pypi.python.org/pypi/${project_name}, but there are various cases where we don't want to use the PyPI project name as project name in anitya. There should be an option to define a custom package name as e.g. in the GitHub backend.

Here's an example: https://release-monitoring.org/project/12300/ The PyPI package is named evdev, but this is confusing as there are various evdev bindings for various languages (which is one of the reasons why Fedora and Mageia prefix such modules with their language name, i.e. python-evdev). Anitya itself had an evdev project already for lua-evdev, which I renamed to the latter to avoid confusion. So here using evdev for the PyPI variant is also not a good solution.

[akien-mga]

Note: For the above-mentioned package I used its GitHub page as workaround to get the latest version. But it doesn't change the fact that the PyPI backend should get support for custom names, as many other packages are likely in such situations.

[jirutka]

I disagree, the project name should IMHO be the official name of the project, not some name you made up. That's probably the reason why PyPI backend doesn't allow to customise the package name, isn't it? Project name may not be unique in Anitya. There is project homepage and distro mappings to disguish various projects with the same name.

[akien-mga]

Then what about projects with the same name, same homepage but different versions? e.g. https://github.com/msgpack/msgpack/releases Should we rename all those to msgpack? https://release-monitoring.org/projects/search/?pattern=msgpack

[akien-mga]

Also, PyPI specifically encourages not to prefix packages with python-, so the upstream name is almost always the name of the library it binds too (in the case of python bindings).

To take my above example again:

• PyPI name: evdev https://pypi.python.org/pypi/evdev
• Upstream name: python-evdev https://github.com/gvalkov/python-evdev http://python-evdev.readthedocs.io/

[jirutka]

I don't know what you mean, each project from this URL has different homepage.

[akien-mga]

I don't know what you mean, each project from this URL has different homepage.

https://release-monitoring.org/project/12278/ https://release-monitoring.org/project/11612/

We're lucky, there are two protocols to access this DNS (http vs https). Good luck if you want to add the java bindings ;)

[jirutka]

Hm, this is a good point, it's not always clear what should be considered as the upstream name.

[akien-mga]

What I mean is that of course there should be some kind of policy about what name to pick for the project on Anitya. But we can't just consider that the name in the PyPI backend has to be the Anitya name, it's more complex than that, so we need more flexibility (as we have for SourceForge, or GitHub).

[pypingou]

There are backends/projects for which the upstream name is unclear but for pypi that is not the case.

So I'd rather keep the pypi backend as it is, the mapping allows distro to specify how they named the project foo from pypi internally.

For bindings as you were showing I think the easiest solution would be to point to the pypi page as homepage rather than the homepage of the project it binds to.

[pypingou]

oh and btw, welcome to the hairy bowl of mess that anitya has to deal with :)

I don't think there is a perfect solution but I'm trying to find the least worst keeping in mind the amazing creativity humans have with project names and versions number and try to reduce the possibility of duplicates in the db (as that would lead to more requests to upstream websites which do not want).

[akien-mga]

That's partly to avoid confusion and unnecessary duplicates that I'd like my package to have a strongly defined name like python-evdev instead of just evdev as used sufficiently on PyPI, but I understand your point.

I think we'd need some kind of "project naming guidelines" (project as in anitya project entry) to ensure that we all follow the same pattern. From my experience with anitya so far I've seen a bit of everything :)

[pypingou]

Guidelines would be great indeed, would you be willing to kick off something? We could then discuss it in the PR and of course adjust as we need :)

[akien-mga]

Sure. I'll start with an issue so that we can brainstorm about it before making a PR.

[yarons]

Also a distinct website because sometimes it's different than the repository itself.