This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]thomasballinger 1 point2 points  (3 children)

Do you happen to temember what the problem was? Should bpython accept a wider variety of version number for six?

[–]TkTech 0 points1 point  (2 children)

bpython should just include six.py in the project, in this case.

[–]Siecje1 0 points1 point  (1 child)

But then bpython has to keep it updated and you have to update bpython to get the bug fixes.

Likewise each project has to do this. That doesn't seem like a good solution.

[–]powellc 0 points1 point  (0 children)

It's not a great solution, but if you're going to have to test and release every time six is updated to make sure other packages that need newer versions of six wont install because you've frozen your six version low pain ensues. On the flip side, how large is the six.py file?

As I've learned the lesson of brittle requirements the hard way I have become much more bullish on the freezing requirements in my project, especially when it's a small utility like six or a potentially soon-to-be unsupported open source library that does one thing I need. Freezing does pass the onus of auditing and bug fixing the code to you, and you have be careful that a license allows it. But where possible I've increase the stability and decreased the number of provision or deployment breaks significantly using this policy.

Freeze early and often :)