alec-gem 2.7.2

data/docs/make.bat

@@ -0,0 +1,155 @@
+@ECHO OFF
+
+REM Command file for Sphinx documentation
+
+if "%SPHINXBUILD%" == "" (
+	set SPHINXBUILD=sphinx-build
+)
+set BUILDDIR=_build
+set ALLSPHINXOPTS=-d %BUILDDIR%/doctrees %SPHINXOPTS% .
+if NOT "%PAPER%" == "" (
+	set ALLSPHINXOPTS=-D latex_paper_size=%PAPER% %ALLSPHINXOPTS%
+)
+
+if "%1" == "" goto help
+
+if "%1" == "help" (
+	:help
+	echo.Please use `make ^<target^>` where ^<target^> is one of
+	echo.  html       to make standalone HTML files
+	echo.  dirhtml    to make HTML files named index.html in directories
+	echo.  singlehtml to make a single large HTML file
+	echo.  pickle     to make pickle files
+	echo.  json       to make JSON files
+	echo.  htmlhelp   to make HTML files and a HTML help project
+	echo.  qthelp     to make HTML files and a qthelp project
+	echo.  devhelp    to make HTML files and a Devhelp project
+	echo.  epub       to make an epub
+	echo.  latex      to make LaTeX files, you can set PAPER=a4 or PAPER=letter
+	echo.  text       to make text files
+	echo.  man        to make manual pages
+	echo.  changes    to make an overview over all changed/added/deprecated items
+	echo.  linkcheck  to check all external links for integrity
+	echo.  doctest    to run all doctests embedded in the documentation if enabled
+	goto end
+)
+
+if "%1" == "clean" (
+	for /d %%i in (%BUILDDIR%\*) do rmdir /q /s %%i
+	del /q /s %BUILDDIR%\*
+	goto end
+)
+
+if "%1" == "html" (
+	%SPHINXBUILD% -b html %ALLSPHINXOPTS% %BUILDDIR%/html
+	echo.
+	echo.Build finished. The HTML pages are in %BUILDDIR%/html.
+	goto end
+)
+
+if "%1" == "dirhtml" (
+	%SPHINXBUILD% -b dirhtml %ALLSPHINXOPTS% %BUILDDIR%/dirhtml
+	echo.
+	echo.Build finished. The HTML pages are in %BUILDDIR%/dirhtml.
+	goto end
+)
+
+if "%1" == "singlehtml" (
+	%SPHINXBUILD% -b singlehtml %ALLSPHINXOPTS% %BUILDDIR%/singlehtml
+	echo.
+	echo.Build finished. The HTML pages are in %BUILDDIR%/singlehtml.
+	goto end
+)
+
+if "%1" == "pickle" (
+	%SPHINXBUILD% -b pickle %ALLSPHINXOPTS% %BUILDDIR%/pickle
+	echo.
+	echo.Build finished; now you can process the pickle files.
+	goto end
+)
+
+if "%1" == "json" (
+	%SPHINXBUILD% -b json %ALLSPHINXOPTS% %BUILDDIR%/json
+	echo.
+	echo.Build finished; now you can process the JSON files.
+	goto end
+)
+
+if "%1" == "htmlhelp" (
+	%SPHINXBUILD% -b htmlhelp %ALLSPHINXOPTS% %BUILDDIR%/htmlhelp
+	echo.
+	echo.Build finished; now you can run HTML Help Workshop with the ^
+.hhp project file in %BUILDDIR%/htmlhelp.
+	goto end
+)
+
+if "%1" == "qthelp" (
+	%SPHINXBUILD% -b qthelp %ALLSPHINXOPTS% %BUILDDIR%/qthelp
+	echo.
+	echo.Build finished; now you can run "qcollectiongenerator" with the ^
+.qhcp project file in %BUILDDIR%/qthelp, like this:
+	echo.^> qcollectiongenerator %BUILDDIR%\qthelp\Sentry.qhcp
+	echo.To view the help file:
+	echo.^> assistant -collectionFile %BUILDDIR%\qthelp\Sentry.ghc
+	goto end
+)
+
+if "%1" == "devhelp" (
+	%SPHINXBUILD% -b devhelp %ALLSPHINXOPTS% %BUILDDIR%/devhelp
+	echo.
+	echo.Build finished.
+	goto end
+)
+
+if "%1" == "epub" (
+	%SPHINXBUILD% -b epub %ALLSPHINXOPTS% %BUILDDIR%/epub
+	echo.
+	echo.Build finished. The epub file is in %BUILDDIR%/epub.
+	goto end
+)
+
+if "%1" == "latex" (
+	%SPHINXBUILD% -b latex %ALLSPHINXOPTS% %BUILDDIR%/latex
+	echo.
+	echo.Build finished; the LaTeX files are in %BUILDDIR%/latex.
+	goto end
+)
+
+if "%1" == "text" (
+	%SPHINXBUILD% -b text %ALLSPHINXOPTS% %BUILDDIR%/text
+	echo.
+	echo.Build finished. The text files are in %BUILDDIR%/text.
+	goto end
+)
+
+if "%1" == "man" (
+	%SPHINXBUILD% -b man %ALLSPHINXOPTS% %BUILDDIR%/man
+	echo.
+	echo.Build finished. The manual pages are in %BUILDDIR%/man.
+	goto end
+)
+
+if "%1" == "changes" (
+	%SPHINXBUILD% -b changes %ALLSPHINXOPTS% %BUILDDIR%/changes
+	echo.
+	echo.The overview file is in %BUILDDIR%/changes.
+	goto end
+)
+
+if "%1" == "linkcheck" (
+	%SPHINXBUILD% -b linkcheck %ALLSPHINXOPTS% %BUILDDIR%/linkcheck
+	echo.
+	echo.Link check complete; look for any errors in the above output ^
+or in %BUILDDIR%/linkcheck/output.txt.
+	goto end
+)
+
+if "%1" == "doctest" (
+	%SPHINXBUILD% -b doctest %ALLSPHINXOPTS% %BUILDDIR%/doctest
+	echo.
+	echo.Testing of doctests in the sources finished, look at the ^
+results in %BUILDDIR%/doctest/output.txt.
+	goto end
+)
+
+:end

data/docs/processors.rst

@@ -0,0 +1,124 @@
+Processors
+==========
+
+Raven Ruby contains several "processors", which scrub data before it is sent to Sentry.
+Processors remove invalid or sensitive data. The following are the processors
+which are enabled by default (and are applied to all outgoing data in this order):
+
+RemoveCircularReferences
+   Many Ruby JSON implementations simply throw an exception if they detect a
+   circular reference. This processor removes circular references from hashes
+   and arrays.
+
+UTF8Conversion
+   Many Ruby JSON implementations will throw exceptions if data is not in a
+   consistent UTF-8 format. This processor looks for invalid encodings and fixes
+   them.
+
+SanitizeData
+  Censors any data which looks like a password, social security number or credit
+  card number. Can be configured to scrub other data.
+
+Cookies
+  Removes any HTTP cookies from the Sentry event data.
+
+PostData
+  Removes any HTTP Post request bodies.
+
+HTTPHeaders
+  Removes all HTTP headers which match a regex. By default, this will only remove the
+  "Authorization" header, but can be configured to remove others.
+
+Finally, another processor is included in the source but is not turned on by default,
+RemoveStackTrace.
+
+To remove stacktraces from events:
+
+.. sourcecode:: ruby
+
+    Raven.configure do |config|
+      config.processors += [Raven::Processor::RemoveStacktrace]
+    end
+
+Writing Your Own Processor
+--------------------------
+
+Processors are simple to write and understand. As an example, let's say that we
+send user API keys to a background job (using Sidekiq), and if the background job
+raises an exception, we want to make sure that the API key is removed from the
+event data.
+
+This is what a basic processor might look like:
+
+.. sourcecode:: ruby
+
+  class MyJobProcessor < Raven::Processor
+    def process(data)
+      return data unless data["extra"]["arguments"] &&
+        data["extra"]["arguments"].first["sensitive_parameter"]
+
+      data["extra"]["arguments"].first["sensitive_parameter"] = STRING_MASK
+      data
+    end
+  end
+
+Processors should inherit from the ``Raven::Processor`` class. This ensures that the
+processor has access to its client (all processors have a ``client`` instance method,
+which will be populated with the current ``Raven::Client`` when the  processor
+is initialized), and gives you a few convenient constants for masking data.
+
+Processors must have a method called ``process`` defined. It must accept one
+argument, which will be the Raven event data hash. The method must return a hash,
+which represents the data after it has been modified by the processor.
+
+To help you in writing your own processor, here is what the Event data hash looks
+like (slightly modified/concatenated) when it is passed to the processor:
+
+.. sourcecode:: ruby
+
+  {
+    "environment" => "default",
+    "event_id" => "02ea6d3d35c840b1a8f339ba896917e3",
+    "extra" => {
+      "server" => {
+       # server related information
+      }
+     "active_job" => "MyActiveJob",
+     "arguments" => [ {"sensitive_parameter": "sensitive"} ],
+     "job_id" => "cbc2c146-0486-4e98-b81c-1a251d636b34",
+    },
+    "modules" => {
+      "rake"=>"12.0.0",
+       "concurrent-ruby"=>"1.0.5",
+       "i18n"=>"0.8.6",
+       "minitest"=>"5.10.3",
+       # ...
+    },
+    "platform" => "ruby",
+    "release" => "e4d5ced",
+    "sdk" => {"name"=>"raven-ruby", "version"=>"2.6.3"},
+    "server_name" => "myserver.local",
+    "timestamp" => "2017-10-09T19:53:20",
+    "exception" => {
+      # A very large and complex exception object
+    }
+  }
+
+However, it will probably be more helpful if you use a debugger, such as `pry`, to
+inspect the event data hash for yourself.
+
+The example processor given above looks for the ActiveJob arguments hash, looks for
+a particular value, and then replaces it with the string mask. There is a fast return
+if the event does not contain the ActiveJob data we're looking for, using Ruby 2.3+'s
+safe navigation operator.
+
+Once you have your processor written, you simply need to add it to the processor chain:
+
+.. sourcecode:: ruby
+
+  Raven.configure do |config|
+    config.processors += MyJobProcessor
+  end
+
+For more information about writing processors, read the code for the default
+processors, located in ``lib/processor``.

data/docs/sentry-doc-config.json

@@ -0,0 +1,31 @@
+{
+  "support_level": "production",
+  "platforms": {
+    "ruby": {
+      "name": "Ruby",
+      "type": "language",
+      "doc_link": "",
+      "wizard": [
+        "index#installation",
+        "index#configuration",
+        "index#reporting-failures"
+      ]
+    },
+    "ruby.rack": {
+      "name": "Rack",
+      "type": "framework",
+      "doc_link": "integrations/rack/",
+      "wizard": [
+        "integrations/rack#rack-sinatra-etc"
+      ]
+    },
+    "ruby.rails": {
+      "name": "Rails",
+      "type": "framework",
+      "doc_link": "integrations/rails/",
+      "wizard": [
+        "integrations/rails#ruby-on-rails"
+      ]
+    }
+  }
+}

data/docs/usage.rst

@@ -0,0 +1,176 @@
+Usage
+=====
+
+To use Raven Ruby all you need is your DSN.  Like most Sentry libraries it
+will honor the ``SENTRY_DSN`` environment variable.  You can find it on
+the project settings page under API Keys.  You can either export it as
+environment variable or manually configure it with ``Raven.configure``:
+
+.. code-block:: ruby
+
+    Raven.configure do |config|
+      config.dsn = '___DSN___'
+    end
+
+If you only want to send events to Sentry in certain environments, you
+should set ``config.environments`` too:
+
+.. code-block:: ruby
+
+    Raven.configure do |config|
+      config.dsn = '___DSN___'
+      config.environments = ['staging', 'production']
+    end
+
+Reporting Failures
+------------------
+
+If you use Rails, Rake, Rack etc, you're already done - no more
+configuration required! Check :doc:`integrations/index` for more details on
+other gems Sentry integrates with automatically.
+
+Otherwise, Raven supports two methods of capturing exceptions:
+
+.. sourcecode:: ruby
+
+    Raven.capture do
+      # capture any exceptions which happen during execution of this block
+      1 / 0
+    end
+
+    begin
+      1 / 0
+    rescue ZeroDivisionError => exception
+      Raven.capture_exception(exception)
+    end
+
+Reporting Messages
+------------------
+
+If you want to report a message rather than an exception you can use the
+``capture_message`` method:
+
+.. code-block:: ruby
+
+    Raven.capture_message("Something went very wrong")
+
+Referencing Events
+------------------
+
+The client exposes a ``last_event_id`` accessor allowing you to easily
+reference the last captured event. This is useful, for example, if you wanted
+to show the user a reference on your error page:
+
+.. code-block:: ruby
+
+    # somewhere deep in the stack
+    Raven.capture do
+      1 / 0
+    end
+
+Now you can easily expose this to your error handler:
+
+.. code-block:: ruby
+
+    class ErrorsController < ApplicationController
+      def internal_server_error
+        render(:status => 500, :sentry_event_id => Raven.last_event_id)
+      end
+    end
+
+Optional Attributes
+-------------------
+
+With calls to ``capture_exception`` or ``capture_message`` additional data
+can be supplied:
+
+  .. code-block:: ruby
+
+      Raven.capture_message("...", :attr => 'value')
+
+.. describe:: extra
+
+    Additional context for this event. Must be a mapping. Children can be any native JSON type.
+
+    .. code-block:: ruby
+
+        {
+            :extra => {'key' => 'value'}
+        }
+
+.. describe:: fingerprint
+
+    The fingerprint for grouping this event.
+
+    .. code-block:: ruby
+
+        {
+            :fingerprint => ['{{ default }}', 'other value']
+        }
+
+.. describe:: level
+
+    The level of the event. Defaults to ``error``.
+
+    .. code-block:: ruby
+
+        {
+            :level => 'warning'
+        }
+
+    Sentry is aware of the following levels:
+
+    * debug (the least serious)
+    * info
+    * warning
+    * error
+    * fatal (the most serious)
+
+.. describe:: logger
+
+    The logger name for the event.
+
+    .. code-block:: ruby
+
+        {
+            :logger => 'default'
+        }
+
+.. describe:: tags
+
+    Tags to index with this event. Must be a mapping of strings.
+
+    .. code-block:: ruby
+
+        {
+            :tags => {'key' => 'value'}
+        }
+
+.. describe:: user
+
+    The acting user.
+
+    .. code-block:: ruby
+
+        {
+            :user => {
+                'id' => 42,
+                'email' => 'clever-girl'
+            }
+        }
+
+Many Instances
+--------------
+
+It is possible to have many different instances and configurations of the Raven
+client running at once. See the delegation pattern in ``base.rb`` for more
+information about how the ``Raven`` module delegates calls to the "main" instance.
+
+.. code-block:: ruby
+
+    Raven.capture # capture, sent to the main instance
+
+    # You can create as many instances as you like. Provide a context and config.
+    instance = Raven::Instance.new(Raven::Context.new, Raven::Configuration.new)
+
+Currently, all integrations use the "main" instance.