Metadata-Version: 2.1
Name: derp
Version: 0.1.0
Summary: command line tool to ensure that deprecated code is removed in a timely manner
Home-page: https://github.com/bfolie/derp
Author: Brendan Folie
Author-email: bfolie@citrine.io
License: MIT
Platform: UNKNOWN
Classifier: Development Status :: 2 - Pre-Alpha
Classifier: Environment :: Console
Classifier: Programming Language :: Python
Classifier: Programming Language :: Python :: 3.5
Classifier: Programming Language :: Python :: 3.6
Classifier: Programming Language :: Python :: 3.7
Classifier: Programming Language :: Python :: 3.8
Classifier: Intended Audience :: Developers
Description-Content-Type: text/markdown

# derp
Derp (Deprecation Enforcement and Removal Planning) is a command-line tool for ensuring that deprecated code is removed from your python package in a timely manner.
Derp scans the application for deprecation flags and ensures that:

1. All deprecations have a planned removal version.
2. Deprecated objects are removed at the planned time.

## Usage

Install derp from pypi using pip: `pip install derp`.
Invoke derp from the command line, specifying the package or module to analyze and the current version of the software.
The command below will scan all modules in `src/my_app` and catch any deprecated code that is supposed to be removed by version 1.0.0.

```python
derp src/my_app 1.0.0
```

The current version can also be read from a file.
If `src/my_app/__version__.py` contains the version number, invoke the following.

```python
derp src/my_app src/my_app/__version__.py
```

Including this command as part of a CI/CD script will ensure that deprecations are done thoughtfully and that deprecated code is removed on schedule.

## Potentially Asked Questions

**Why use derp?**

Derp was inspired by the belief that a lean codebase is more pleasant to work in,
and as such deprecated code should be cleaned out as soon as is feasible.
Including derp in your CI/CD pipeline pushes developers to clean out deprecated code.

**What if I don't know when I want to remove a deprecated item?**

"Next major version bump" is a good default.

**What if I need to keep a deprecated item around longer than expected?**

Increase the planned removal version.
It's fine for deprecated code to stick around longer than expected, but it should happen intentionally, not because nobody got around to clearing it out.

**What type of deprecations does derp catch?**

On classes and methods, derp catches a single `@deprecation()` annotation.

**What if I use a different deprecation tool or want to deprecate something that's neither a class nor a method?**

Tell me about your use case, and I might add it.
Alternatively, open a PR.
See "derp/deprecation.py" for a discussion of how to add more types of deprecations.

**What if I include multiple deprecation annotations?**

Don't do that.
Why are you doing that?

OK fine, if there's a legitimate reason to do this, let me know and I'll think about supporting it.

**Couldn't I use the @fail_if_not_removed decorator?**

Yeah, but that requires a developer to be conscientious every time they deprecate something.
You have to voluntarily point it to the version number, select a removal version, and add `@fail_if_not_removed` on all relevant tests.
It's easier to just slap `@deprecated()` with no arguments, move on, and forget about it.
Derp will chide you: "you need to select a removal version."
And when that version comes around it will poke you again: "time to remove this code."

