Feel free to contribute to tunesynctool. Always test your code thoroughly manually and if possible, via automated tests.

Credit

Contributors will be credited on this page.

• @Kyrluckechuck

---

Bug fixes and other small changes

Please limit your pull requests to a handful of related bug fixes or changes. This is so we can have separate discussions for each problem under different PRs and it makes it easier to merge them.

Drivers

Drivers are "modules" that provide abstractions for streaming services. They follow implement the same ServiceDriver abstract base class. This allows the users of tunesynctool to interact with all services in a unified way.

The downside of this is that some methods have to raise an exception if they can't be directly implemented. Another downside with this approach is that we can't just randomly implement functionality on a per-service basis because we have to make sure that most of the other services also have similar functionality and other drivers can implement it just as easily.

Methods in drivers should "directly map" to API endpoints or functions. For example, the search method should return as much metadata about its results as possible, because it is used for track matching. Other methods, unless absolutely necessary, should make only a single API request and return the resulting object, even with most of it's fields empty (None).

Mappers

Mappers should never be exposed to the end users. Mappers are internal classes that map API responses (text, JSON, XML, whatever) to the data model classes in tunesynctool. Track and Playlist are such classes, for example. The mappers subclass the same abstract base class (ServiceMapper). Unless absolutely necessary, stick to the interface defined in the abstract base class. The YouTube Music mapper is an exception to this, but you should avoid this.