This talk presents different methods to handle dependencies to external libraries in QGIS plugins. Compared to for example web development world there is no wide adoption of general-purpose QGIS libraries available nor a way to easily integrate such libraries into own plugin or library development. Also, some widely-used non-QGIS-specific libraries like pandas for data manipulation might be beneficial for QGIS plugins or libraries to use as well. Built-in QGIS features include declaring dependency plugins, but the usage must rely on either accessing the plugin instance and its API, importing code of the plugin package in a guarded way, or using only for example the processing providers installed by such dependency plugins. For example, sharing and using general purpose GUI components, simple functions etc. with an external, possibly pip-installable dependency library is not straightforward and has many obstacles. Some methods used include requesting dependency install manually from the user, using subprocess calls to install the dependencies automatically, shipping dependencies together with the plugin code and using import paths manipulation, or bundling the dependencies into the code and using replaced imports to point to the bundled library. Difficulties in some or all these approaches include possible version conflicts between different plugin requirements, version mismatches with the expected runtime and platform incompatibility. This talk compares these different methods pros and cons, possible use cases for each, effect on the development workflow, and shows available tools for helping to use some of these methods.