On Mon, Sep 16, 2013 at 12:37 AM, Kiran Jonnalagadda <j...@pobox.com> wrote:
>
>
> Pinned requirements == complacency == future breakage, when maintenance is
> much more expensive than it is today.
imo there are is two underlying independent issues here. Having said
that let me state that while I pin requirements.txt, and started
responding to this thread earlier with a bit of ambivalence on the
issue, I have moved closer to the pinning requirements.txt as an
appropriate solution for me as the thread has evolved.
1) Complacency :
This simply has to do with how frequently one does builds / creates
dists that are used for deployment. A scenario where one continuously
recreates a fresh virtualenv and regenerates requirements.txt "before"
everytime one re-runs a test-suite, should fix it. It is not tied to
whether a requirements.txt is being used or not. I am still working
through what is the implication for automation for dealing with this.
Clearly one would need to find a way of associating a version / tag /
commit with a last successfully tested requirement.txt. I am not yet
sure of how one would go around doing that. Though that is something I
intend to spend time on.
2) Repeatability : Was the software you tested, the software you
deployed. This could be fixed by one of multiple approaches
a) Bundled dependencies
b) Pinned requirements.txt
I acknowledge the implication in terms of potential rot. I think I
shall be working on fixing (1) without compromising on (2) rather than
treating them as mutually exclusive.
There are too many contextual variables here, so please don't assume I
am making a recommendation. The above seems to be the best I think I
should be doing. YMMV.
_______________________________________________
BangPypers mailing list
BangPypers@python.org
https://mail.python.org/mailman/listinfo/bangpypers
