Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Conflict with 'statsd' install dir #42

Open
kaidokert opened this issue May 28, 2016 · 4 comments
Open

Conflict with 'statsd' install dir #42

kaidokert opened this issue May 28, 2016 · 4 comments
Assignees

Comments

@kaidokert
Copy link

pip install statsd python-statsd
results in a mess in site-packages. Unlikely to be a real issue, only noticed because i was trying to figure out the differences between these and pystatsd, statsd-client

@wolph
Copy link
Owner

wolph commented May 28, 2016

Perhaps I should add some detection to see if the conflicting version is installed. It's a bit unfortunate that @jsocol and I chose the same name when starting the packages but nearly impossible to change that now since many projects depend on either of the packages.

One option could be to create a compatibility layer so they function with the same API. Although I would argue that my API is currently more Pythonic. To illustrate:

>>> import statsd
>>> counter = statsd.Counter('foo')
>>> counter += 10

Versus:

>>> import statsd
>>> client = statsd.StatsClient()
>>> client.incr('foo', 10)

The examples for timers show similar differences.

@jsocol
Copy link

jsocol commented May 28, 2016

Honestly, it never occurred to me that someone would install both in the same virtualenv.

@kaidokert
Copy link
Author

Yeah i didn't plan on installing them side by side either, so its a very minor thing. Like i said, i only noticed because i was looking at various statsd client options available.

@wolph
Copy link
Owner

wolph commented May 28, 2016

So far in the years I've maintained this package you're the 2nd to report this so you're definitely not alone :)

Perhaps I'll add some API compatibility and/or checks, should be good

@wolph wolph self-assigned this Jun 11, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants