0

I am looking for a way to express something that resembles NPM's peerDependencies in setuptools.

My Python library is a plugin that should work with another Python library that I don't want to have as a dependency. Instead I'd like my end user to be responsible for it and install it by themselves. I can't find a proper way to express this in Python's setuptools (or any other build for that matter), to let my user "know" about the library

From my current understanding, this is a close approximation between the tools:

NPM setuptools
dependencies install_requires
optionalDependencies extras_require
peerDependencies ???

I have two possible solutions, both of which I find lacking:

  1. Use extras_require anyway

    Specify my requirements under an extras_require will do the job, but it feels like abusing it, because the user shouldn't install these extras.

  2. Just document it

    Inform the user that they need to install that package separately. Feels lame too

jonrsharpe
  • 115,751
  • 26
  • 228
  • 437
mati.o
  • 1,398
  • 1
  • 13
  • 23

1 Answers1

3

To my understanding, there is no need for that, as Python handles dependencies different anyway.

With npm/node you can have multiple versions of one package withing the same environment, if it required by one of the sub-dependencies (How does NPM handle version conflicts?)

This is not possible in Python. Only a single version of a library can be installed in the one environment. This means that the general issue that you are trying to solve with peer-dependencies, can not happen.

My recommendation is to specify your dependencies as normal, but with a loose version specifier.

arthaigo
  • 423
  • 4
  • 10
  • 1
    Good points! I have not given enough thought to python’s version conflicts resolution. So, basically if my plugin lib needs the external lib, it will be good to loosely specify it. The app will declare its more specific version if needed and they’ll settle on that one. The result is the same anyway. – mati.o Mar 23 '22 at 12:16
  • We have an issue that there are different versions of the `torch` library depending on which version of CUDA your environment has installed. Our library requires `torch`, but the user of our library is the only one who can determine which version of `torch` needs to be installed. (Note: this is not "which version" like "2.0 or 3.0", nor environment like "windows vs linux", but environment like "what hardware driver do you have installed." See this for more details: https://github.com/python-poetry/poetry/issues/6409 – Eric Jul 25 '23 at 13:17