  Third-party libraries are a cornerstone of fast application development. To
enable efficient use, libraries must provide a well-designed API. An obscure
API instead slows down the learning process and can lead to erroneous use.
  The usual approach to improve the API of a library is to edit its code
directly, either keeping the old API but deprecating it (temporarily increasing
the API size) or dropping it (introducing breaking changes). If maintainers are
unwilling to make such changes, others need to create a hard fork, which they
can refactor. But then it is difficult to incorporate changes to the original
library, such as bug fixes or performance improvements.
  In this paper, we instead explore the use of the adapter pattern to provide a
new API as a new library that calls the original library internally. This
allows the new library to leverage all implementation changes to the original
library, at no additional cost. We call this approach adaptoring. To make the
approach practical, we identify API transformations for which adapter code can
be generated automatically, and investigate which transformations can be
inferred automatically, based on the documentation and usage patterns of the
original library. For cases where automated inference is not possible, we
present a tool that lets developers manually specify API transformations.
Finally, we consider the issue of migrating the generated adapters if the
original library introduces breaking changes. We implemented our approach for
Python, demonstrating its effectiveness to quickly provide an alternative API
even for large libraries.
