FWIW, I don't think we should be pinning versions in either requirements.txt
*or* in resultsdb.spec, unless we really know that we really do need a specific
version or a constrained version. It makes things much harder to package if
the versions are present here (in particular for things like EPEL7).
Cheers!
It shouldn't affect much.
| Automatic diff as part of commit; lint not applicable. |
| Automatic diff as part of commit; unit tests not applicable. |
Well, we (as in FedoraQA) had this discussion many times, and you should have the conversation with @kparal :) I always just let it go after an afternoon of heated discussion.
On a similar topic - my understanding of requirement.txt is, that you actually _should_ pin versions, to have repeatability. I have been bitten many times by (for example) Flask changing on the fly, and breaking the underlying code.
Even with knowing that stuff needs to be ported to EPEL, I'd rather pin to versions available in EPEL, to be sure of what we have to work with.