Package name should NOT be "analytics", rename to segment/segmentio about analytics-python HOT 29 CLOSED

I'll transfer the name across if segment want to keep it updated

On 25 Oct 2016 21:06, "Prateek Srivastava" [email protected] wrote:

@graingert https://github.com/graingert's wrapper is following it's own
versioning scheme (independent of analytics-python's versioning). If you
download the source code from https://pypi.python.org/pypi/segment/0.2.0,
you'll see it has the latest relevant changes (commit in our repo #79
#79, and in segment
package on pypi https://cloudup.com/c4EegesqVjE).

Effectively it's up to to date with version 1.2.5

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#42 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAZQTIfjwhwCauHaIpPlhD88Pw9-ruxmks5q3mFMgaJpZM4DwM3I
.

from analytics-python.

+1

It's kind of a pain to workaround this when we have a local app in our django project already called analytics.

from analytics-python.

👍

from analytics-python.

👍

from analytics-python.

+1

from analytics-python.

👍

from analytics-python.

@alvinchow86 you can solve the import collision by turning off implicit relative imports in Python 2.7 with

from __future__ import absolute_import

However this has been a big readability hassle for us as we had lots of code written generically for whatever analytics service(s) we'd use, and when we switched to Segment it became unreadable.

We now do:

import analytics as segment

etc. everywhere we use it!

from analytics-python.

@alvinchow86 @adamchainz We can, but shouldn't have to do that.

I find that use of "import ... as" is often an anti-pattern or a code smell —Guido

http://code.activestate.com/lists/python-ideas/30361/

from analytics-python.

Is it possible to consider changing this package name, or do I need to change it locally and rebase every time there is an update?

from analytics-python.

pip install segment

import segment

from analytics-python.

@graingert you better keep that up to date

from analytics-python.

This is an exceptionally valid issue. My org is running into this issue right now and it appears many others are.

Let's not be unreasonable and come up with a valid solution, please. 👍

from analytics-python.

@tuxxy probably better to stick with pip install segment I'm happy to add contributors to the project

from analytics-python.

@graingert that seems like a good solution. Thought the segment version doesn't seem to have been updated in a long time (v0.2.0 instead of anaytics-python v1.2.5). Could it be updated with every new github release for the analytics-python repo?

from analytics-python.

@graingert why is the version v0.2.0 and not v1.2.5 if it's suppose to be just a wrapper?

Why should I use your repo/pip?

from analytics-python.

@graingert's fork is following it's own versioning scheme (independent of analytics-python's versioning). If you download the source code from https://pypi.python.org/pypi/segment/0.2.0, you'll see it has the latest relevant changes (commit in our repo #79, and in segment package on pypi https://cloudup.com/c4EegesqVjE).

Effectively it's up to to date with version 1.2.5

Updated: I meant fork not wrapper (since it's basically analytics-python with references replaced)

from analytics-python.

It's not a wrapper

On 25 Oct 2016 20:51, "Dylan Gregersen" [email protected] wrote:

@graingert https://github.com/graingert why is the version v0.2.0 and
not v1.2.5 if it's suppose to be just a wrapper?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#42 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAZQTCc60zctQ_lF_4abpT6JLZd6yTDbks5q3l2vgaJpZM4DwM3I
.

from analytics-python.

+1

from analytics-python.

+1

from analytics-python.

I've created a renamed version 1.2.8 at https://pypi.python.org/pypi/segmentio for anyone who needs it. Repo at https://github.com/jamiemccrindle/segmentio.

from analytics-python.

Thanks @jamiemccrindle. We have this same issue.

from analytics-python.

Tracking internally here as well https://segment.atlassian.net/browse/LIB-115

from analytics-python.

Renaming the package name to segment doesn't seem like a practical solution here. Here's a good discussion (albeit in Ruby) around this rails/journey#49 (comment).

#42 (comment)

This seems like a reasonable workaround. Are there any practical concerns to not using this (other than Guido's comment from http://code.activestate.com/lists/python-ideas/30361)

from analytics-python.

from analytics-python.

@graingert I don't think's a practical solution here - someone could easily have a module named segment and we'll be back to square one.

What are your arguments against #42 (comment)?

from analytics-python.

That's fine because it matches your PyPI name

from analytics-python.

@f2prateek 'as' imports are a bit ugly, and make the code harder to read. If you can just rename it once and solve it for everyone then that is the easiest path

from analytics-python.

I don't understand why you're worried that someone's going to have a module named segment but not worried that someone's going to have a module named analytics. Analytics is a common module name I've seen in 6 different companies so far; probably nobody else is calling their module segment except for you guys, and I'm sure they would be empathetic if they had a conflict since you have a brand around it.

from analytics-python.

I have the following concerns with renaming to segment:

• Making people have to update their code and migrate their implementations to accomadete this change
• It's also about consistency, we have 10 other using the same name analytics (https://github.com/segmentio?utf8=✓&q=analytics&type=&language=).
• the problem isn't fully 100% mitigated. I understand how fewer people will run into a conflict with the name segment than with analytics, but nevertheless there will still be people that run into this.

There is a reasonably low friction workaround proposed as well #42 (comment). If there are issues with the workaround in #42 (comment) let us know and we can reconsider.

Otherwise breaking backward compatibility just for a name change is not something we're prepared to do at the moment.

from analytics-python.