PyPI name clash for 'eta'

[jayvdb]

I would like to start packaging this for openSUSE , but to do that I need a PyPI identifier for it.

setup.py uses ETA, but that clashes with https://pypi.org/project/ETA/ which is https://github.com/mbreese/eta/

Please find a unique name, and reserve it even before the first release, so alpha/beta rpms can be built.

[jasoncorso]

Thanks for the note. We'll visit this question ASAP and address.
One question: https://github.com/mbreese/eta has not been touched in 4 years. Is there any expiry on it for PyPI?

[jayvdb]

Unfortunately there is no expiry.

You could ask them if they want to transfer the name to you, but it is unlikely as they have other packages which depend on eta, e.g. https://github.com/mbreese/hpt/blob/master/requirements.txt

[jasoncorso]

We checked with mbreese and he declined against transfering the name to us.

Question, as I could not find an answer on PyPI. Can we name the PyPI package as something like voxel51-eta or libeta or... but still maintain the library name as eta (as in import eta.core.video)?

[brimoor]

We can definitely name as voxel51-eta without affecting import syntax. This is what we’ll do with other libraries anyway. Would have been slightly cooler to have ‘eta’, but ‘voxel51-eta’ will do just fine.

…

On Mar 29, 2019, at 2:13 PM, Jason Corso ***@***.***> wrote: We checked with mbreese and he declined against transfering the name to us. Question, as I could not find an answer on PyPI. Can we name the PyPI package as something like voxel51-eta but still maintain the library name as eta (as in import eta.core.video)? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[jayvdb]

Yea, that is fine in this case.

In distro world, if there were users wanting both eta and voxel51-eta, we would mark the two packages as 'Conflicts' so users can not install both together, as they would overwrite each other. It happens occasionally, and is especially annoying if both are irreplaceable pieces of software. An example is the file binary/library offers a python library called magic, and there is a PyPI package called python-magic. Thankfully the author of the latter, which has grown into the slightly better of the two, is going to add a compatibility shim so users of the file library can transparently become users of his library.

However I cant see that happening here, based on what we know. What we dont know is if there is another import eta lurking in PyPI database hiding behind a different name, or another GitHub repo slowly growing mature using that name completely unaware of this repo.