# Dependency Management for Libraries

**URL:** <https://discourse.processing.org/t/dependency-management-for-libraries/18940>\
**Category:** Development\
**Created:** [March 23, 2020, 4:31pm UTC](https://discourse.processing.org/t/dependency-management-for-libraries/18940 "2020-03-23T16:31:54Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![cansik](https://yyz2.discourse-cdn.com/flex036/user_avatar/discourse.processing.org/cansik/32/8815_2.png) [@cansik](https://discourse.processing.org/u/cansik)\
**Post date:** [March 23, 2020, 4:31pm UTC](https://discourse.processing.org/t/dependency-management-for-libraries/18940/1 "2020-03-23T16:31:54Z")

</div>

At the moment I am working on a new library for Processing which is based on OpenCV. The binary files of OpenCV are about ~400 MB, with all contribution libraries, we are talking about ~700 MB to download. As this maybe won’t be the only library containing the OpenCV binaries, it would make sense for me to at least depend on Gregs already existing OpenCV lib (even it’s a bit outdated).

Of course there are other scenarios, where it would make sense to use already contributed libraries and build on them. For the Processing user it should be a no-brainer to download them and all the necessary dependencies (inside the contribution manager).

While searching through the forum and github, it seems that the need for dependency management is there, but was always to complex to implement:

- [Can one user library use another?](https://discourse.processing.org/t/can-one-user-library-use-another/10949)
- [https://github.com/processing/processing/issues/5937](https://github.com/processing/processing/issues/5937)

So I would like to propose a very limited, but simple solution that could be implemented quite fast:

We just use the `library.properties` file and add a new line to it, which tells the contribution manager, on which libraries this library is based. The contribution manager then just goes through the list, downloads each library (and of course their dependencies) and installs them. This is the most tricky part, because we have to create a dependency graph and remove cycles, but that should be solvable (because there is no version locking atm).

```ini
name=Intel RealSense for Processing
category=Hardware
authors=The Author
url=https://github.com/cansik/realsense-processing
sentence=Intel RealSense support for Processing
paragraph=Use the Intel RealSense (https://realsense.intel.com/) cameras together with Processing.
version=212000
prettyVersion=2.1.2
minRevision=0
maxRevision=0

# dependencies (PeasyCam, oscP5)
dependencies=17,118

```

The library id is assigned by the Contribution Manager manager. You can find the current list here:  
[http://download.processing.org/contribs/](http://download.processing.org/contribs/)

It would be just a very simple tool, but could be really helpful. Most of my libraries use PeasyCam, oscP5 or some other really basic library. Letting the user to always download them himself is a bit cumbersome and not really “beginner friendly”.

Of course I know, that this won’t solve all our problems and it is not a fully fledged dependency management for Processing. It’s just one step into that direction.

Would be great to here what other library developers think about this idea.

---

<div class="post-metadata">

**Author:** ![jeremydouglass](https://yyz2.discourse-cdn.com/flex036/user_avatar/discourse.processing.org/jeremydouglass/32/20_2.png) [@jeremydouglass](https://discourse.processing.org/u/jeremydouglass)\
**Post date:** [March 28, 2020, 5:55pm UTC](https://discourse.processing.org/t/dependency-management-for-libraries/18940/2 "2020-03-28T17:55:52Z")

</div>

This seems like a great idea to me.

I think that a dependency should also have required min version and optional max version. If you want to punt on them, you can use “0” for no min and no max.

```auto
# dependencies (PeasyCam, oscP5)
dependencies=17.198.0, 118.0.0

```

Here we need PeasyCam version 198 or higher, and any old oscP5. The number is the version integer, not the prettyVersion string

This way if we get breaking information on dependency incompatibility then the dependency version range numbers can be updated – and the library installer could give a helpful warning at install time about peasyCam being missing / lower than #a / higher than #b. Even if those features aren’t implemented, they could be in the future.

---

<div class="post-metadata">

**Author:** ![jeremydouglass](https://yyz2.discourse-cdn.com/flex036/user_avatar/discourse.processing.org/jeremydouglass/32/20_2.png) [@jeremydouglass](https://discourse.processing.org/u/jeremydouglass)\
**Post date:** [June 25, 2020, 6:41pm UTC](https://discourse.processing.org/t/dependency-management-for-libraries/18940/3 "2020-06-25T18:41:04Z")

</div>

A recent related discussion regarding similar issues with Box2D rather than OpenCV:

> [@What's the best way to handle multiple libraries using the same imports](https://discourse.processing.org/t/whats-the-best-way-to-handle-multiple-libraries-using-the-same-imports/20577/2):
>
> I believe that this is here: cross-linking: The issue is not just that they are using the same underlying library – it is also that they might be using different versions of that library. Previous discussions: [https://forum.processing.org/two/discussion/577/boxwrap2d-vs-pbox2d](https://forum.processing.org/two/discussion/577/boxwrap2d-vs-pbox2d)[https://forum.processing.org/two/discussion/1040/how-to-deploy-library-that-requires-processing-s-serial-class](https://forum.processing.org/two/discussion/1040/how-to-deploy-library-that-requires-processing-s-serial-class) One approach would be to create a fork of any or all of them, Box2DThin, FisicaThin, LiquidFunThin t…