Legend offset new attribute

[doutriaux1]

@danlipsa a few baselines are still missing (Linux) it is ready for review.

goes with: CDAT/uvcdat-testdata#149

[kwrobot]

Basic content checks failed!

commit 7b37eb85 adds bad whitespace:
testing/vcs/test_vcs_legend_2.py:55: new blank line at EOF.

commit 221e44ee adds bad whitespace:
Packages/vcs/vcs/template.py:1765: trailing whitespace.
+                    startLength, 
Packages/vcs/vcs/template.py:1770: trailing whitespace.
+                        startThick, 
Packages/vcs/vcs/template.py:1772: trailing whitespace.
+                        startThick + thick, 
testing/vcs/test_vcs_legend.py:55: new blank line at EOF.

commit 58e6d05b adds bad whitespace:
Packages/vcs/vcs/template.py:1741: trailing whitespace.
+        L = [] # length 

Branch-at: 63ba8e8
Rejected-by: @kwrobot

[doutriaux1]

@danlipsa @aashish24 @mcenerney1 this is needed for ACME improvement. Please review.

[danlipsa]

@doutriaux1 @aashish24 Why do so many baselines change? What is offset? I would squash related commits. A commit such as 'pep8ed and flake8ed' has no value in history - it only create noise.

[doutriaux1]

@danlipsa so many baseline changes because the legend is slightly different now. offset is the distance of the legend labels from the colorbar. peped8 and such commits have value to me because they are cosmetic changes and they make it harder to follow the changes that actually happened in the process. Going commit by commit helps reviewing and we can happily skip the pep8 ones. I personally don't like PR with ONE commit, I like to see the work that went in nd follow the thought process. History is mostly useless once a PR is in anyway.

[danlipsa]

@doutriaux1 I agree that adding extra commits makes reviewing easier - this is one place many commits is better than a squashed commit. We use the history in ParaView and VTK to track regressions that would otherwise take longer to fix.

[doutriaux1]

@danlipsa I see. Feel free to squash commits if it really bothers you.

[danlipsa]

@doutriaux1 Can you expand the comment for offset to include the detailed explanation in the comments section?

[danlipsa]

@doutriaux1 Besides my comments, the changes look reasonable.

[danlipsa]

@doutriaux1 I can live without squashed commits :-) I thought it might help us if we need to go back to a previous valid version. But maybe this is more than we need for uvcdat.

[kwrobot]

Basic content checks failed!

commit ac8580af has committer name "GitHub" with no space.  Run
  git config --global user.name 'Your Name'
  git config --global user.email 'you@yourdomain.com'
before creating commits.
commit 7b37eb85 adds bad whitespace:
testing/vcs/test_vcs_legend_2.py:55: new blank line at EOF.

commit 221e44ee adds bad whitespace:
Packages/vcs/vcs/template.py:1765: trailing whitespace.
+                    startLength, 
Packages/vcs/vcs/template.py:1770: trailing whitespace.
+                        startThick, 
Packages/vcs/vcs/template.py:1772: trailing whitespace.
+                        startThick + thick, 
testing/vcs/test_vcs_legend.py:55: new blank line at EOF.

commit 58e6d05b adds bad whitespace:
Packages/vcs/vcs/template.py:1741: trailing whitespace.
+        L = [] # length 

Changes since last check: compare

Branch-at: ac8580a
Rejected-by: @kwrobot

[doutriaux1]

@danlipsa this is ready for final review all test pass on my mac and linux, and they should all pass on travis once this is merged in fix_travis.I can merge in master.

[danlipsa]

@doutriaux1 Why do you need to do this?

[doutriaux1]

@danlipsa because sometimes the environement does not get activated. I suspect some concurency issues within conda, too many process trying to activate at same time, so I keep trying until it's actually activated. We could/should probably improve the test to see if it's activated (using conda env list or something like that) but that would be another PR.

[danlipsa]

@doutriaux1 I see. Thanks!

[danlipsa]

@doutriaux1 LGTM 👍

[danlipsa]

@doutriaux1 @aashish24 Here is some discussion on squashing commits
http://programmers.stackexchange.com/questions/263164/why-squash-git-commits-for-pull-requests
No pressure though 😄

[doutriaux1]

not convinced. If it's for the reviewer that cares for the "net effect" then just look at this on the PR. Now if that is not enough and the reviewer wants to look at the history in detail then it's easy better I think to ignore the pep8ed commit and look at the previous one which has only the changes made, rather than a bi commit with a bunch of useless pep8ed changes in it that had to what really changed. Anyhow, feel free to squash them if you feel like the history would be better.