Version bump to 1.13.0 and initial documentation for deprecation of sentry.client

CHANGES

@@ -1,3 +1,8 @@
+
+1.13.0
+
+* Deprecated the Sentry client, and added Raven to the as the default builtin.
+
 1.12.1
 
 * Stabilize migration schema (solves problem with index creation fail introduced in 1.12.0).

README.rst

@@ -1,11 +1,17 @@
-------
 Sentry
-------
+======
 
 Sentry provides you with a generic interface to view and interact with your error logs. By
 default, it will catch any exception thrown by Django and store it in a database. With this
 it allows you to interact and view near real-time information to discover issues and more
 easily trace them in your application.
 
+Sentry Client Changes
+---------------------
+
+As of 1.13.0 the built-in client has been deprecated. A new standalone project (which doesn't require Django)
+called `Raven <http://github.com/dcramer/raven>`_ will replace it. If you're just getting started
+with Sentry, or you want to use a client in a non-Django application, we suggest taking a look at Raven.
+
 
 Docs: http://readthedocs.org/docs/sentry/en/latest/index.html

docs/config/index.rst

@@ -1,131 +1,7 @@
 Configuration
 =============
 
-This document describes additional configuration options available to Sentry.
-
-.. note:: While these are prefixed with ``SENTRY_`` in your ``settings.py``, if you were to configure or reference them via
-          Sentry's internal tools the prefix would be dropped.
-
-          For example, ``SENTRY_PUBLIC`` would be ``sentry.conf.settings.PUBLIC``.
-
-
-Integration with ``logging``
-----------------------------
-
-Sentry supports the ability to directly tie into the ``logging`` module. To use it simply add ``SentryHandler`` to your logger.
-
-
-Django 1.3
-~~~~~~~~~~
-
-::
-
-    LOGGING = {
-        'version': 1,
-        'disable_existing_loggers': True,
-        'root': {
-            'level': 'WARNING',
-            'handlers': ['sentry'],
-        },
-        'formatters': {
-            'verbose': {
-                'format': '%(levelname)s %(asctime)s %(module)s %(process)d %(thread)d %(message)s'
-            },
-        },
-        'handlers': {
-            'sentry': {
-                'level': 'DEBUG',
-                'class': 'sentry.client.handlers.SentryHandler',
-                'formatter': 'verbose'
-            },
-            'console': {
-                'level': 'DEBUG',
-                'class': 'logging.StreamHandler',
-                'formatter': 'verbose'
-            }
-        },
-        'loggers': {
-            'sentry.errors': {
-                'level': 'DEBUG',
-                'handlers': ['console'],
-                'propagate': False,
-            },
-        },
-    }
-
-
-Older Versions
-~~~~~~~~~~~~~~
-
-::
-
-    import logging
-    from sentry.client.handlers import SentryHandler
-
-    logger = logging.getLogger()
-    # ensure we havent already registered the handler
-    if SentryHandler not in map(type, logger.handlers):
-        logger.addHandler(SentryHandler())
-
-        # Add StreamHandler to sentry's default so you can catch missed exceptions
-        logger = logging.getLogger('sentry.errors')
-        logger.propagate = False
-        logger.addHandler(logging.StreamHandler())
-
-
-Usage
-~~~~~
-
-A recommended pattern in logging is to simply reference the modules name for each logger, so for example, you might at the top of your module define the following::
-
-    import logging
-    logger = logging.getLogger(__name__)
-
-You can also use the ``exc_info`` and ``extra=dict(url=foo)`` arguments on your ``log`` methods. This will store the appropriate information and allow django-sentry to render it based on that information::
-
-	logger.error('There was some crazy error', exc_info=True, extra={'url': request.build_absolute_uri()})
-
-You may also pass additional information to be stored as meta information with the event. As long as the key
-name is not reserved and not private (_foo) it will be displayed on the Sentry dashboard. To do this, pass it as ``data`` within
-your ``extra`` clause::
-
-	logger.error('There was some crazy error', exc_info=True, extra={
-	    # Optionally pass a request and we'll grab any information we can
-	    'request': request,
-
-	    # Otherwise you can pass additional arguments to specify request info
-	    'view': 'my.view.name',
-	    'url': request.build_absolute_url(),
-
-	    'data': {
-	        # You may specify any values here and Sentry will log and output them
-	        'username': request.user.username
-	    }
-	})
-
-.. note:: The ``url`` and ``view`` keys are used internally by Sentry within the extra data.
-.. note:: Any key (in ``data``) prefixed with ``_`` will not automatically output on the Sentry details view.
-
-Sentry will intelligently group messages if you use proper string formatting. For example, the following messages would
-be seen as the same message within Sentry::
-
-	logger.error('There was some %s error', 'crazy')
-	logger.error('There was some %s error', 'fun')
-	logger.error('There was some %s error', 1)
-
-As of Sentry 1.10.0 the ``logging`` integration also allows easy capture of stack frames (and their locals) as if you were
-logging an exception. This can be done automatically with the ``SENTRY_AUTO_LOG_STACKS`` setting, as well as by passing the
-``stack`` boolean to ``extra``::
-
-	logger.error('There was an error', extra={'stack': True})
-
-.. note::
-
-    We are describing a client/server interaction where
-    both components are provided by django-sentry.  Other languages that
-    provide a logging package that is comparable to the python ``logging``
-    package may define a sentry handler.  Check the:ref:`Extending Sentry <extending-sentry>`
-    documentation.
+This document describes additional configuration options available to the Sentry server. If you are looking for documentation for the client, it is maintained in the `Raven <http://github.com/dcramer/raven>`_ project.
 
 Integration with ``haystack`` (Search)
 --------------------------------------
@@ -158,109 +34,10 @@ When calling Haystack's Django management commands, you'll need to identify Sent
 
 Enjoy!
 
-404 Logging
------------
-
-.. versionadded:: 1.6.0
-
-In certain conditions you may wish to log 404 events to the Sentry server. To do this, you simply need to enable a Django middleware::
-
-	MIDDLEWARE_CLASSES = MIDDLEWARE_CLASSES + (
-	  ...,
-	  'sentry.client.middleware.Sentry404CatchMiddleware',
-	)
-
-Message References
-------------------
-
-.. versionadded:: 1.6.0
-
-Sentry supports sending a message ID to your clients so that they can be tracked easily by your development team. There are two ways to access this information, the first is via the ``X-Sentry-ID`` HTTP response header. Adding this is as simple as appending a middleware to your stack::
-
-	MIDDLEWARE_CLASSES = MIDDLEWARE_CLASSES + (
-	  # We recommend putting this as high in the chain as possible
-	  'sentry.client.middleware.SentryResponseErrorIdMiddleware',
-	  ...,
-	)
-
-Another alternative method is rendering it within a template. By default, Sentry will attach request.sentry when it catches a Django exception. In our example, we will use this information to modify the default 500.html which is rendered, and show the user a case reference ID. The first step in doing this is creating a custom ``handler500`` in your ``urls.py`` file::
-
-	from django.conf.urls.defaults import *
-
-	from django.views.defaults import page_not_found, server_error
-
-	def handler500(request):
-	    """
-	    500 error handler which includes ``request`` in the context.
-
-	    Templates: `500.html`
-	    Context: None
-	    """
-	    from django.template import Context, loader
-	    from django.http import HttpResponseServerError
-
-	    t = loader.get_template('500.html') # You need to create a 500.html template.
-	    return HttpResponseServerError(t.render(Context({
-	        'request': request,
-	    })))
-
-Once we've successfully added the request context variable, adding the Sentry reference ID to our 500.html is simple::
-
-	<p>You've encountered an error, oh noes!</p>
-	{% if request.sentry.id %}
-	    <p>If you need assistance, you may reference this error as <strong>{{ request.sentry.id }}</strong>.</p>
-	{% endif %}
-
 Other Settings
 --------------
 
-Several options exist to configure django-sentry via your ``settings.py``:
-
-SENTRY_CLIENT
-~~~~~~~~~~~~~~
-
-In some situations you may wish for a slightly different behavior to how Sentry communicates with your server. For
-this, Sentry allows you to specify a custom client::
-
-	SENTRY_CLIENT = 'sentry.client.base.SentryClient'
-
-In addition to the default client (which will handle multi-db and REMOTE_URL for you) we also include two additional options:
-
-LoggingSentryClient
-*******************
-
-Pipes all Sentry errors to a named logger: ``sentry``. If you wish to use Sentry in a strictly client based logging mode
-this would be the way to do it.
-
-::
-
-	SENTRY_CLIENT = 'sentry.client.log.LoggingSentryClient'
-
-CelerySentryClient
-******************
-
-Integrates with the Celery message queue (http://celeryproject.org/). To use this you will also need to add ``sentry.client.celery`` to ``INSTALLED_APPS`` for ``tasks.py`` auto discovery.
-
-You may also specify ``CELERY_ROUTING_KEY`` to change the task queue
-name (defaults to ``sentry``).
-
-::
-
-	SENTRY_CLIENT = 'sentry.client.celery.CelerySentryClient'
-
-	INSTALLED_APPS = (
-	    ...,
-	    'sentry.client.celery',
-	)
-
-AsyncSentryClient
-*****************
-
-Spawns a background thread within the process that will handle sending messages upstream.
-
-::
-
-	SENTRY_CLIENT = 'sentry.client.async.AsyncSentryClient'
+Several options exist to configure django-sentry via your configuration module:
 
 SENTRY_ADMINS
 ~~~~~~~~~~~~~
@@ -296,57 +73,16 @@ SENTRY_MAIL_EXCLUDE_LOGGERS
 
 An explicit list of all logger names to exclude from emails. Defaults to ``[]``.
 
-SENTRY_TESTING
-~~~~~~~~~~~~~~
-
-Enabling this setting allows the testing of Sentry exception handler even if Django ``DEBUG`` is enabled.
-
-Default value is ``False``
-
-.. note:: Normally when Django DEBUG is enabled the Sentry exception handler is immediately skipped
-
-SENTRY_NAME
-~~~~~~~~~~~
-
-This will override the ``server_name`` value for this installation. Defaults to ``socket.gethostname()``.
-
 SENTRY_URL_PREFIX
 ~~~~~~~~~~~~~~~~~
 
 Absolute URL to the sentry root directory. Should not include a trailing slash. Defaults to ``""``.
 
-SENTRY_EXCLUDE_PATHS
-~~~~~~~~~~~~~~~~~~~~
-
-Extending this allow you to ignore module prefixes when we attempt to discover which function an error comes from (typically a view)
-
-SENTRY_INCLUDE_PATHS
-~~~~~~~~~~~~~~~~~~~~
-
-By default Sentry only looks at modules in INSTALLED_APPS for drilling down where an exception is located
-
-SENTRY_MAX_LENGTH_LIST
-~~~~~~~~~~~~~~~~~~~~~~
-
-The maximum number of items a list-like container should store. Defaults to ``50``.
-
-SENTRY_MAX_LENGTH_STRING
-~~~~~~~~~~~~~~~~~~~~~~~~
-
-The maximum characters of a string that should be stored. Defaults to ``200``.
-
 SENTRY_PUBLIC
 ~~~~~~~~~~~~~
 
 Should Sentry be protected by a username and password (using @login_required) or be publicly accessible. Defaults to ``False`` (password protection).
 
-SENTRY_AUTO_LOG_STACKS
-~~~~~~~~~~~~~~~~~~~~~~
-
-.. versionadded:: 1.10.0
-
-Should Sentry automatically log frame stacks (including locals) for ``create_from_record`` (``logging``) calls as it would for exceptions. Defaults to ``False``.
-
 SENTRY_SAMPLE_DATA
 ~~~~~~~~~~~~~~~~~~
 

docs/index.rst

@@ -6,6 +6,14 @@ default, it will catch any exception thrown by Django and store it in a database
 it allows you to interact and view near real-time information to discover issues and more
 easily trace them in your application.
 
+Sentry Client Changes
+---------------------
+
+As of 1.13.0 the built-in client has been deprecated. A new standalone project (which doesn't require Django)
+called `Raven <http://github.com/dcramer/raven>`_ will replace it. If you're just getting started
+with Sentry, or you want to use a client in a non-Django application, we suggest taking a look at Raven.
+
+
 .. toctree::
    :maxdepth: 2
 

docs/install/index.rst

@@ -1,4 +1,3 @@
-=======
 Install
 =======
 
@@ -10,7 +9,6 @@ Or with *setuptools*::
 
 	easy_install -U django-sentry
 
-------------
 Requirements
 ------------
 
@@ -21,6 +19,7 @@ you will need to install the following packages in your Sentry server environmen
  - ``django-indexer >= 0.3.0`` (stores metadata indexes)
  - ``django-paging >= 0.2.4``
  - ``django-templatetag-sugar >= 0.1.0``
+ - ``raven >= 0.2``
 
 .. note::
 
@@ -40,24 +39,25 @@ You now have two choices:
    most compatibility with your application, as well as ensuring it does not impact your
    primary application servers.
 
-----------------
 Integrated Setup
 ----------------
 
 The integrated setup is the easiest to get up and running. It simply requires you to plug the Sentry application into your existing
-Django project. Once installed, you simply need to update your settings.py and add ``sentry`` and ``sentry.client`` to ``INSTALLED_APPS``::
+Django project. Once installed, you simply need to update your settings.py and add ``sentry`` and ``raven.contrib.django`` to ``INSTALLED_APPS``::
 
 	INSTALLED_APPS = (
 	    'django.contrib.admin',
 	    'django.contrib.auth',
 	    'django.contrib.contenttypes',
 	    'django.contrib.sessions',
-	    
+
 	    'sentry',
-	    'sentry.client',
+	    'raven.contrib.django',
 	    ...
 	)
 
+.. note:: Raven is a seperate project, and the official Python client for Sentry.
+
 You will also need to add ``sentry.web.urls`` to your url patterns::
 
 	urlpatterns = patterns('',
@@ -81,15 +81,13 @@ Finally, run ``python manage.py syncdb`` to create the database tables.
 
    See :doc:`../extensions` for information on additional plugins and functionality included.
 
-#########
 Upgrading
-#########
+~~~~~~~~~
 
 Upgrading Sentry is fairly painless with South migrations. If you're not using South then you're on your own::
 
 	python manage.py migrate sentry
 
------------------------
 Running a Sentry Server
 -----------------------
 
@@ -98,9 +96,8 @@ logging. This means that any number of Sentry clients simply pass on this inform
 server. If you run into a situation where one of Sentry's requirements conflict with your own, or you simply
 need to ensure quality of service within your project, this is for you.
 
-###################
 The Built-in Server
-###################
+~~~~~~~~~~~~~~~~~~~
 
 Sentry provides a built-in webserver (powered by eventlet) to get you off the ground quickly. It's powered by two open source
 libraries, eventlet and python-daemon. To get started, you will need to manually install those dependicies::
@@ -110,7 +107,7 @@ libraries, eventlet and python-daemon. To get started, you will need to manually
 
 Sentry provides the start, stop, and restart commands available via the command line interface to manage the server process::
 
-	# Sentry's server runs on port 9000 by default. Make sure your ``SENTRY_REMOTE_URL`` reflects
+	# Sentry's server runs on port 9000 by default. Make sure your ``SENTRY_SERVERS`` settings reflects
 	# the correct host and port!
 	sentry start --config=/etc/sentry.conf.py
 
@@ -124,7 +121,7 @@ configuration via --config, you will likely want to preface the file with import
 
 	#!/usr/bin/env python
 	# filename: /etc/sentry.conf.py
-	
+
 	DATABASES = {
 	    'default': {
 	        'ENGINE': 'django.db.backends.postgresql_psycopg2',
@@ -135,9 +132,9 @@ configuration via --config, you will likely want to preface the file with import
 	        'PORT': '',
 	    }
 	}
-	
+
 	SENTRY_LOG_FILE = '/var/log/sentry.log'
-        SENTRY_WEB_HOST = '0.0.0.0'
+    SENTRY_WEB_HOST = '0.0.0.0'
 	SENTRY_WEB_PORT = 9000
 
 By default, Sentry will also look for ``~/.sentry/sentry.conf.py`` and load it if it exists, and ``--config`` is not passed.
@@ -148,33 +145,27 @@ By default, Sentry will also look for ``~/.sentry/sentry.conf.py`` and load it i
 
 The following settings are available for the built-in webserver:
 
-********
 WEB_HOST
-********
+````````
 
 The hostname which the webserver should bind to. Defaults to ``localhost``.
 
-********
 WEB_PORT
-********
-
+````````
 The port which the webserver should listen on. Defaults to ``9000``.
 
-************
 WEB_PID_FILE
-************
+````````````
 
 The location to store the PID file. Defaults to ``/var/run/sentry.pid``.
 
-************
 WEB_LOG_FILE
-************
+````````````
 
 The location to store the log file. Defaults to ``/var/log/sentry.log``.
 
-#############################
 Configuring a Sentry WSGI app
-#############################
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 If you need more flexibility in your Sentry server, you may want to setup the server project manually. While this guide does not
 cover configuring your webserver, it does describe the required attributes of your WSGI app to run in a standalone server mode.
@@ -186,7 +177,7 @@ First you're going to need to add Sentry to your server's INSTALLED_APPS::
 	  'sentry',
 	  # We recommend adding the client to capture errors
 	  # seen on this server as well
-	  'sentry.client',
+	  'raven.contrib.django',
 	]
 
 You will also need to ensure that your ``SENTRY_KEY`` matches across your client and server configurations::
@@ -194,9 +185,8 @@ You will also need to ensure that your ``SENTRY_KEY`` matches across your client
 	SENTRY_KEY = '0123456789abcde'
 
 
-######################
 Configure your Clients
-######################
+~~~~~~~~~~~~~~~~~~~~~~
 
 On each of your application servers, you will need to configure Sentry to communicate with your remote Sentry server.
 
@@ -204,50 +194,15 @@ Start with adding the client to your ``INSTALLED_APPS``::
 
 	INSTALLED_APPS = [
 	  ...
-	  'sentry.client',
+	  'raven.contrib.django',
 	]
 
-Add the ``SENTRY_REMOTE_URL`` configuration variable, to point to the absolute location to the ``/store/`` view on your
+Add the ``SENTRY_SERVERS`` configuration variable, to point to the absolute location to the ``/store/`` view on your
 Sentry server::
 
 	# This should be the absolute URI of sentries store view
-	SENTRY_REMOTE_URL = 'http://your.sentry.server/sentry/store/'
+	SENTRY_SERVERS = 'http://your.sentry.server/sentry/store/'
 
 You will also need to ensure that your ``SENTRY_KEY`` matches across your client and server configurations::
 
 	SENTRY_KEY = '0123456789abcde'
-
-
--------
-Caveats
--------
-
-#########################
-Error Handling Middleware
-#########################
-
-If you already have middleware in place that handles ``process_exception`` you will need to take extra care when using Sentry.
-
-For example, the following middleware would suppress Sentry logging due to it returning a response::
-
-	class MyMiddleware(object):
-	    def process_exception(self, request, exception):
-	        return HttpResponse('foo')
-
-To work around this, you can either disable your error handling middleware, or add something like the following::
-
-	from django.core.signals import got_request_exception
-	class MyMiddleware(object):
-	    def process_exception(self, request, exception):
-	        # Make sure the exception signal is fired for Sentry
-	        got_request_exception.send(sender=self, request=request)
-	        return HttpResponse('foo')
-
-Or, alternatively, you can just enable Sentry responses::
-
-	from sentry.client.models import sentry_exception_handler
-	class MyMiddleware(object):
-	    def process_exception(self, request, exception):
-	        # Make sure the exception signal is fired for Sentry
-	        sentry_exception_handler(request=request)
-	        return HttpResponse('foo')

docs/technical/index.rst

@@ -71,6 +71,8 @@ Writing a Client
 
 *work in progress!*
 
+For an example client, you may want to take a look at `Raven <http://github.com/dcramer/raven>`_.
+
 This section describes how to write a Sentry client.  As far as the
 writer is concerned, a Sentry client *is* a logging handler written in
 a language different than Python.  You will not find the
@@ -81,7 +83,7 @@ implement just a Sentry client in your own language or framework.
 In general, the action taken by a logging handler compatible with
 ``log4j`` and ``logging`` is doing something with a timestamped
 attributable formatted logging record.  Every logging record has its
-own severity level.  
+own severity level.
 
 :timestamped: ``timestamp`` is the time the event happened.
 :attributable: ``logger`` is the name of the logger that produced the record.
@@ -117,7 +119,7 @@ To generate the HMAC signature, take the following example (in Python)::
 
 The variables which are required within the signing of the message consist of the following:
 
-- The ``SENTRY_KEY`` is a the shared secret key between client and server. 
+- The ``SENTRY_KEY`` is a the shared secret key between client and server.
 - ``timestamp`` is the timestamp of which this message was generated
 - ``message`` is the encoded :ref:`POST Body`
 
@@ -126,7 +128,7 @@ POST Body
 
 The body of the post is a string representation of a JSON object and is
 (optionally and preferably) gzipped and then (necessarily) base64
-encoded.  
+encoded.
 
 This JSON object contains the following fields:
 

example_project/settings.py

@@ -100,7 +100,7 @@ INSTALLED_APPS = (
     'django.contrib.sites',
     'django.contrib.messages',
     'sentry',
-    'sentry.client',
+    'raven.contrib.django',
     'sentry.plugins.sentry_redmine',
     'sentry.plugins.sentry_servers',
     'sentry.plugins.sentry_sites',
@@ -140,7 +140,7 @@ else:
     INSTALLED_APPS = INSTALLED_APPS + (
         'debug_toolbar',
     )
-    
+
     MIDDLEWARE_CLASSES = MIDDLEWARE_CLASSES + (
         'debug_toolbar.middleware.DebugToolbarMiddleware',
     )

sentry/client/base.py

@@ -49,7 +49,7 @@ class SentryClient(object):
     def check_throttle(self, checksum):
         if not (settings.THRASHING_TIMEOUT and settings.THRASHING_LIMIT):
             return (False, None)
-        
+
         cache_key = 'sentry:%s' % (checksum,)
         # We MUST do a get first to avoid re-setting the timeout when doing .add
         added = cache.get(cache_key) is None
@@ -59,7 +59,7 @@ class SentryClient(object):
 
         if added:
             return (False, None)
-        
+
         try:
             thrash_count = cache.incr(cache_key)
         except (KeyError, ValueError):
@@ -76,16 +76,16 @@ class SentryClient(object):
     @fail_silently()
     def get_last_message_id(self, checksum):
         cache_key = 'sentry:%s:last_message_id' % (checksum,)
-        
+
         return cache.get(cache_key)
 
     @fail_silently()
     def set_last_message_id(self, checksum, message_id):
         if settings.THRASHING_TIMEOUT and settings.THRASHING_LIMIT:
             cache_key = 'sentry:%s:last_message_id' % (checksum,)
-        
+
             cache.set(cache_key, message_id, settings.THRASHING_LIMIT + 5)
-        
+
     def process(self, **kwargs):
         "Processes the message before passing it on to the server"
         from sentry.utils import get_filters
@@ -113,7 +113,7 @@ class SentryClient(object):
                 GET=request.GET,
                 COOKIES=request.COOKIES,
             ))
-            
+
             if hasattr(request, 'user'):
                 if request.user.is_authenticated():
                     user_info = {
@@ -150,13 +150,13 @@ class SentryClient(object):
             modules = get_installed_apps()
             if settings.INCLUDE_PATHS:
                 modules = set(list(modules) + settings.INCLUDE_PATHS)
-        
+
             def contains(iterator, value):
                 for k in iterator:
                     if value.startswith(k):
                         return True
                 return False
-            
+
             # We iterate through each frame looking for an app in INSTALLED_APPS
             # When one is found, we mark it as last "best guess" (best_guess) and then
             # check it against SENTRY_EXCLUDE_PATHS. If it isnt listed, then we
@@ -175,7 +175,7 @@ class SentryClient(object):
                     break
             if best_guess:
                 view = best_guess
-        
+
             if view:
                 kwargs['view'] = view
 
@@ -212,12 +212,12 @@ class SentryClient(object):
                     'id': '%s$%s' % (message_id, checksum),
                     'thrashed': True,
                 }
-            
+
             return message_id
-            
+
         for filter_ in get_filters():
             kwargs = filter_(None).process(kwargs) or kwargs
-        
+
         # create ID client-side so that it can be passed to application
         message_id = uuid.uuid4().hex
         kwargs['message_id'] = message_id
@@ -229,17 +229,17 @@ class SentryClient(object):
             kwargs['timestamp'] = datetime.datetime.now()
 
         self.send(**kwargs)
-        
+
         if request:
             # attach the sentry object to the request
             request.sentry = {
                 'id': '%s$%s' % (message_id, checksum),
                 'thrashed': False,
             }
-        
+
         # store the last message_id incase we hit thrashing limits
         self.set_last_message_id(checksum, message_id)
-        
+
         return message_id
 
     def send_remote(self, url, data, headers={}):
@@ -252,16 +252,16 @@ class SentryClient(object):
 
     def send(self, **kwargs):
         "Sends the message to the server."
-        if settings.REMOTE_URL:
+        if settings.SERVERS:
             message = base64.b64encode(json.dumps(kwargs).encode('zlib'))
-            for url in settings.REMOTE_URL:
+            for url in settings.SERVERS:
                 timestamp = time.time()
                 signature = get_signature(message, timestamp)
                 headers = {
                     'Authorization': get_auth_header(signature, timestamp, '%s/%s' % (self.__class__.__name__, sentry.VERSION)),
                     'Content-Type': 'application/octet-stream',
                 }
-                
+
                 try:
                     return self.send_remote(url=url, data=message, headers=headers)
                 except urllib2.HTTPError, e:
@@ -275,7 +275,7 @@ class SentryClient(object):
                     logger.log(kwargs.pop('level', None) or logging.ERROR, kwargs.pop('message', None))
         else:
             from sentry.models import GroupedMessage
-            
+
             return GroupedMessage.objects.from_kwargs(**kwargs)
 
     def create_from_record(self, record, **kwargs):
@@ -285,20 +285,20 @@ class SentryClient(object):
         for k in ('url', 'view', 'request', 'data'):
             if not kwargs.get(k):
                 kwargs[k] = record.__dict__.get(k)
-        
+
         kwargs.update({
             'logger': record.name,
             'level': record.levelno,
             'message': force_unicode(record.msg),
             'server_name': settings.NAME,
         })
-        
+
         # construct the checksum with the unparsed message
         kwargs['checksum'] = construct_checksum(**kwargs)
-        
+
         # save the message with included formatting
         kwargs['message'] = record.getMessage()
-        
+
         # If there's no exception being processed, exc_info may be a 3-tuple of None
         # http://docs.python.org/library/sys.html#sys.exc_info
         if record.exc_info and all(record.exc_info):
@@ -348,7 +348,7 @@ class SentryClient(object):
             exc_info = sys.exc_info()
 
         data = kwargs.pop('data', {}) or {}
-        
+
         try:
             exc_type, exc_value, exc_traceback = exc_info
 
@@ -363,14 +363,14 @@ class SentryClient(object):
             data['__sentry__']['frames'] = frames
             data['__sentry__']['exception'] = [exc_module, exc_value.args]
 
-            # As of r16833 (Django) all exceptions may contain a ``django_template_source`` attribute (rather than the 
+            # As of r16833 (Django) all exceptions may contain a ``django_template_source`` attribute (rather than the
             # legacy ``TemplateSyntaxError.source`` check) which describes template information.
             if hasattr(exc_value, 'django_template_source') or ((isinstance(exc_value, TemplateSyntaxError) and \
                 isinstance(getattr(exc_value, 'source', None), (tuple, list)) and isinstance(exc_value.source[0], LoaderOrigin))):
                 origin, (start, end) = getattr(exc_value, 'django_template_source', exc_value.source)
                 data['__sentry__']['template'] = (origin.reload(), start, end, origin.name)
                 kwargs['view'] = origin.loadname
-        
+
             tb_message = '\n'.join(traceback.format_exception(exc_type, exc_value, exc_traceback))
 
             kwargs.setdefault('message', transform(force_unicode(exc_value)))

sentry/client/models.py

@@ -16,19 +16,21 @@ from django.core.signals import got_request_exception
 
 from sentry.conf import settings
 
+warnings.warn('sentry.client will be removed in version 1.14.0. You should switch to raven.client.django', DeprecationWarning)
+
 logger = logging.getLogger('sentry.errors')
 
-if settings.REMOTE_URL:
+if settings.SERVERS:
     class MockTransaction(object):
         def commit_on_success(self, func):
             return func
-        
+
         def is_dirty(self):
             return False
-    
+
         def rollback(self):
             pass
-    
+
     transaction = MockTransaction()
 else:
     from django.db import transaction
@@ -56,7 +58,7 @@ def sentry_exception_handler(request=None, **kwargs):
         extra = dict(
             request=request,
         )
-        
+
         message_id = get_client().create_from_exception(**extra)
     except Exception, exc:
         try:

sentry/conf/defaults.py

@@ -46,9 +46,9 @@ LOG_LEVELS = (
 )
 
 # This should be the full URL to sentries store view
-REMOTE_URL = None
+SERVERS = None
 
-REMOTE_TIMEOUT = 5
+TIMEOUT = 5
 
 ADMINS = []