0

Let's say I have some library "foo" and I have it listed as dependency of my project. For example in Python I have requirements file saying

foo==1.0

foo library needs "bar" library and it lists it as dependency. At one point I realize "bar" can be useful for my project too, and I have an idea of calling some function of "bar" directly. So I add

import bar

somewhere in my project code.

Should I now add bar library to my project dependencies? If I don't add it my build system will not complain about missing bar because bar is already required and installed by foo. What is recommended practice in case like this?

Pawelmhm
  • 103
  • 4
  • The day you no longer need `foo`, you'll be thankful you added `bar` to your list of dependencies. After all, it _is_ a dependency. – Vincent Savard Jun 07 '16 at 13:49
  • The day you call a function from bar is the day you add it to your list of dependencies. If you don't need it yet, don't import it. – Snoop Jun 07 '16 at 13:54

1 Answers1

1

It won't hurt.

  • It's explicit. Relying on someone else's dependencies looks a bit like cheating. it works, but it's like you were abusing the dependency tree feature.

  • You may remove foo one day, and be very surprised that your app stopped working for a cryptic dependency reason.

  • You may upgrade foo, and the newer version could be using a new version of bar. it appears that the developers of foo did a great job of migrating their code, but yours still uses the old version of bar. Actually, the new foo may even not use bar at all.

  • foo may use an old version of bar which doesn't have the features you need, so you may be interested in having a dependency to the newer version.

Note that if you actually need to run two different versions of the same package within the same app, you may be in trouble.

Community
  • 1
Arseni Mourzenko
  • 134,780
  • 31
  • 343
  • 513