opentracing / basictracer-python Goto Github PK

Would it be possible to publish a release? We are seeing some folks bit by #43 which does have a workaround but people are learning it the hard way.

Hi,
I'm curious about the subtraction of 1 when generating new ID. Why is it here? The output of random.Random().getrandbits(k) is already in range [0,2^(k-1)], so subtracting 1 can result in new ID equal to -1 (even though with probability 1/2^64).

This is blocking my current project: #40

mind releasing a patch?
@yurishkuro

Could you move the buildsystem to PEP517?

It looks like the generated file is in the repo, but not the Proto source?

Usage of dash-separated 'description-file' will not be supported in future versions. Please use the underscore name 'description_file' instead
https://bugs.gentoo.org/816609

A trivial fix is needed in setup.cfg

This is really a pip bug, but the following stack trace came from a mature python+django installation that already used protobuf locked at 2.6.1... it did not play nice with the proto stuff in basictracer-py.

Traceback (most recent call last):
  File "manage.py", line 14, in <module>
    execute_from_command_line(sys.argv)
  File "/appenv/local/lib/python2.7/site-packages/django/core/management/__init__.py", line 385, in execute_from_command_line
    utility.execute()
  File "/appenv/local/lib/python2.7/site-packages/django/core/management/__init__.py", line 345, in execute
    settings.INSTALLED_APPS
  File "/appenv/local/lib/python2.7/site-packages/django/conf/__init__.py", line 46, in __getattr__
    self._setup(name)
  File "/appenv/local/lib/python2.7/site-packages/django/conf/__init__.py", line 42, in _setup
    self._wrapped = Settings(settings_module)
  File "/appenv/local/lib/python2.7/site-packages/django/conf/__init__.py", line 94, in __init__
    mod = importlib.import_module(self.SETTINGS_MODULE)
  File "/usr/lib/python2.7/importlib/__init__.py", line 37, in import_module
    __import__(name)
  File "/appenv/REDACTED/settings.py", line 13, in <module>
    import lightstep.tracer
  File "/appenv/local/lib/python2.7/site-packages/lightstep/tracer.py", line 11, in <module>
    from basictracer import BasicTracer
  File "/appenv/local/lib/python2.7/site-packages/basictracer/__init__.py", line 3, in <module>
    from .tracer import BasicTracer
  File "/appenv/local/lib/python2.7/site-packages/basictracer/tracer.py", line 6, in <module>
    from .propagation import BinaryPropagator, TextPropagator
  File "/appenv/local/lib/python2.7/site-packages/basictracer/propagation.py", line 9, in <module>
    from .wire_pb2 import TracerState
  File "/appenv/local/lib/python2.7/site-packages/basictracer/wire_pb2.py", line 22, in <module>
    serialized_pb=_b('\n\nwire.proto\x12\x13\x62\x61sictracer_go.wire\"\xc1\x01\n\x0bTracerState\x12\x10\n\x08trace_id\x18\x01 \x01(\x06\x12\x0f\n\x07span_id\x18\x02 \x01(\x06\x12\x0f\n\x07sampled\x18\x03 \x01(\x08\x12I\n\rbaggage_items\x18\x04 \x03(\x0b\x32\x32.basictracer_go.wire.TracerState.BaggageItemsEntry\x1a\x33\n\x11\x42\x61ggageItemsEntry\x12\x0b\n\x03key\x18\x01 \x01(\t\x12\r\n\x05value\x18\x02 \x01(\t:\x02\x38\x01\x42\x06Z\x04wireb\x06proto3')
TypeError: __init__() got an unexpected keyword argument 'syntax'

make lint gives tons of errors. Once fixed, we should change .travis.yml to say make test lint

Is there a reason for not using latest opentracing-python 1.3.0?

https://github.com/opentracing/basictracer-python/blob/master/setup.py#L25

[Edit] updated link.

Per @cybergrind's comment:

Unfortunately protobuf tests aren't fine on python 3 due discrepancies in implementation of bytearray support
https://travis-ci.org/opentracing/basictracer-python/jobs/153806259
Looks like protocolbuffers/protobuf#1173 caused it

I believe we can get rid of jumpahead now just to not break current applications that aren't rely on protobuf serialization and fix tests in separate branch. Btw it isn't look like it going to be fixed in nearest future in protobuf repo.

It looks like setup.py depends on https://pypi.python.org/pypi/futures but doesn't use it anywhere in the code. Was it intended to depend on https://pypi.python.org/pypi/future ? Note the singular future, not the plural futures.

I had some weird bug where this concurrent.futures library was shadowing the python3.5 built-in library which led me here. Although I can't repro my original problem anymore it seemed strange that this package depends on futures.

When I was testing with the earlier 2.0.dev1 version, I could say references=opentracing.child_of(x). Now it breaks because the code always expects references to be an array. Is that intentional?

It seems the user must call tracer.register_required_propagators() after instantiating the tracer. Why is that necessary? I would've expected that can to be made internally from the constructor.