Move appropriate pip dependencies to bundles

[Greg Couch]

As a policy, how about moving the various pip requirements from prereqs/pips to the various packages that actually need them. So, for example, the openvr package wouldn't have been added to prereqs/pips, but instead added to tools/vive/setup.py.in in the install_requires list. We can do the same for all of the packages including core, so all of the dependencies are explicit, and prereqs/pips are only for packages used for building chimerax, not for running chimerax.

[pett]

Since 1.2 is an "infrastructure/build system" release, I milestoned this to 1.2, though we could certainly let it slip as needed. My best guess as to who to assign it to was Greg.

[goddard@…]

I think this is a sensible idea.  But how do we handle the version numbers for packages that several bundles use?  We certainly need all bundles that use a package to use the same version of that package.  Perhaps like in Chimera 1 we have a central Makefile (foreign.make in Chimera1) that contains the version numbers mk/pipversions.make with lines like

PYPI_SCIPY_VERSION = 1.5.2

And what happens when a third-party Toolshed package includes a PyPi dependency with a conflicting version?  What do we tell third-party developers to do to list their dependencies?

[Greg Couch]

With the new pip, third-party packages will not install if they need an incompatible version of a dependency. And the same goes for installing our bundles during the build process. So that should be caught early.

[goddard@…]

We don't want Toolshed bundles to fail due to version incompatibilities with PyPi modules they need.  So maybe we need to recommend that developers use PyPi dependencies that are not too restrictive, like "version >= 4" instead of what we do in our Chimerax prereqs  "version == 4.0.5".

[pett]

Exactly, otherwise two different third party packages could become unnecessarily mutually exclusive by depending on different exact version numbers of the same PyPi package.

[Greg Couch]

Won't make 1.3.

[Zach Pearson]

It was premature of me to say this ticket was blocked by #6434. What that ticket is actually blocking is optional dependencies.

[Zach Pearson]

Where two or more bundles have the same dependency, should we leave the prerequisite in app_requirements.txt for now?

[goddard@…]

We should discuss the pros and cons of moving PyPi dependencies into bundles before any are moved.  One con is that moving them will make it a pain to update dependency version numbers since they will be spread all over the place.   Another downside, is different bundles might specify different versions of a dependency. Different versions can't be installed, so a second bundle will probably clobber the version requested by the first bundle.  I guess that is why you suggest keeping packages used by 2 or more bundles in prereqs.  But any package currently used by one bundle, tomorrow might be used in two bundles when a new bundle is added.  This seems to require careful thinking and discussion.