Python package name conflicts with existing package

[MarkCBell]

Installing the python-snappy wrappings for (Google's) snappy via:
$ pip install python-snappy
installs the python package as snappy. This conflicts with the existing Python package SnapPy which can be installed via:
$ pip install snappy
As a result, if SnapPy is already installed then many systems become confused. For example, dask can use (Google's) snappy and so looks tries to see whether import snappy works. If SnapPy has been installed then this will succeed but load the wrong package and as a result dask will crash.

[martindurant]

We are aware of this. Do you have a suggestion of what to do about it?

[funny-falcon-at-joomcode]

name it a bit different? pysnappy

[martindurant]

Well, this one did come first, I think :) (and this one has >50x the downloads according to pypistats)
Also, pysnappy already exists, and a rename is very tricky.
Perhaps this package should be abandoned in favour of cramjam ???

[funny-falcon-at-joomcode]

Well, this one did come first, I think :)

Nope. SnapPy is from 2009. snappy compression format were opensourced in 2011.

[martindurant]

https://pypi.org/project/snappy/#history maybe cuts off... Anyway, not important.

[andrix]

Chiming in here (original author of the library).

Python Snappy was uploaded to PyPi in 2011 - https://libraries.io/pypi/python-snappy using the name python-snappy to follow a convention on libraries that are wrappers or bindings to C/C++ libraries.

Based on the information by Libraries.io, the first release on PyPi by SnapPy is from 2014: https://libraries.io/pypi/snappy.

It doesn't matter if SnapPy is from 2009 because PyPi is by far the most used source to install packages in python since late 2000's, I think that as matter of consistence, any change should be done by SnapPy on naming to avoid conflicts with this library.

I understand it might break code, but with a good plan it can be done. And judging by the numbers on Libraries.io, SnapPy has less dependencies, and also, it's less popular.

I would recommend to Close this one @martindurant as Won't fix, as it doesn't make sense to me.

[andrix]

Closing the issue as renaming is not easy, and as I mentioned, python-snappy is earlier than SnapPy in PyPi, and also more popular.

[MarkCBell]

Just to add, after waiting a year for progress to be made on this, I patched dask to check more carefully whether the installed snappy is SnapPy or python-snappy. dask/dask#4908

This means that at least dask can be run and does not crash when used in an environment where SnapPy is installed, which was the problem that I originally encountered and lead to me creating this issue.

[martindurant]

@MarkCBell , that seems very reasonable.

[martindurant]

(I realise that fsspec also does this: https://github.com/intake/filesystem_spec/blob/master/fsspec/compression.py#L124 )

[funny-falcon-at-joomcode]

Looking on this it seems to me that Go's authors were somewhat right.

[andrix]

@funny-falcon-at-joomcode - It's indeed a problem, and Russ Cox article it's very good: https://research.swtch.com/deps.

Thanks @MarkCBell and @martindurant