Lock setup dependencies

[jgwerner]

Locks setup dependencies to patch versions.

[rkdarst]

I'm wondering what was the motivation for locking all dependencies? I normally strongly discourage anyone distributing packages from doing this, for the reasons here: https://scicomp.aalto.fi/scicomp/packaging-software/#don-t-pin-dependencies

Practically... how do people usually deal with this? I have someone working with me on nbgrader work now, and I was a bit surprised to see this since I remember it being more specific about problem dependencies before. Except for this pull request diff, how does someone which of these requirements are real, vs needed for one particular deployment? How does one co-install with other things which have a different update cycle? (well, the practical answer is "pip ignores dependency versions", which sort of shows how locking versions isn't really needed anyway...)

I clearly have opinions here, but I'm wondering what others tend to do. I would definitely support a separate lockfile or some such that says "these versions work". Also, practically speaking, it makes more sense for nbgrader rather than other projects, since it's not actively maintained, so maybe it needs to be locked, because we know it's going to break someday anyway, and no one will be around to fix it quickly.

[perllaghu]

The primary reason, from my point of view, is to ensure that the application works as intended.

The other version is that up-stream updates can change APIs, and break services..... witness the fun NBGrader had with NBConvert - when it changed from 5.6.1 to 6.0.0

[BertR]

I clearly have opinions here, but I'm wondering what others tend to do. I would definitely support a separate lockfile or some such that says "these versions work". Also, practically speaking, it makes more sense for nbgrader rather than other projects, since it's not actively maintained, so maybe it needs to be locked, because we know it's going to break someday anyway, and no one will be around to fix it quickly.

@rkdarst : I think your last paragraph hits a good point, this was done because we wanted to make sure there was a working branch, and new CI runs were failing because of broken dependencies.
I we could do some work to establish the range of working versions, we could relax the pinning of the dependencies. eg. notebook<7.0.0. For some packages that are fairly stable (requests, tornado) we can consider removing the pins altogether.

Thoughts @rkdarst , @jgwerner & @perllaghu ?

[jgwerner]

@BertR I would agree that we need a range of working versions to avoid conflicts. I have something locally that accomplishes this requirement. I haven't updated the requirements in a few weeks so will review the packages and send a PR for review.