Details
-
Type:
RFC
-
Status: Implemented
-
Resolution: Done
-
Component/s: DM
-
Labels:None
-
Location:this ticket
Description
We have been allowing developers to list as many or as few direct dependencies as they wish in the ups file of a package, as long as the chain of dependencies includes everything needed. I propose that we recommend that every package list all direct dependencies in the ups file because:
- It is more robust against changes in dependent packages. If package A depends on B and C, and B depends on C, then it is sufficient for A to only list B as a dependency. But if B is later changed to not rely on C then this breaks A in a way that is surprising.
- It makes the dependencies of the package explicit to readers of the code.
- It reduces the need to understand the dependency tree of dependent packages.
This is clearly a contentious issue so I am directly assigning it to K-T
There has been some recent discussion of this RFC in HipChat. I adopted it on 2015-06-10, based partly on " I don't care enough about this to carry the fight further" and "but I'm not going to try to block this RFC because of it" and because I thought (and still think) that transparency of dependencies and which ones need to be specified is important both for programs and for people. I regret that it has not been implemented by incorporation into the developer documents; I will try (after this week) to find an appropriate place for it.
As stated before, the issue with "umbrella" packages like pipe_tasks or afw is that it is difficult to determine whether a given "import lsst.x" statement in Python is legal or not based solely on a "setupRequired()" of the umbrella package in the table file. That information has to come from external documentation somewhere or a search through multiple potential locations, rather than a single, package-local, machine- and human-readable location.
I think the current state of our packaging is such that (direct) build-only and test-only dependencies are appropriate to mention; this distinguishes "standard" LSST packages from other packages (usually third-party ones) that do not require scons and sconsUtils, and a small amount of boilerplate does not seem highly objectionable. We need a better mechanism for handling system dependencies, but that is a separate RFC.