Changes to baseline software versions

dm-dev
Tags: #<Tag:0x00007f7f72fa3270>

(Tim Jenness) #1

Today I have updated the baseline versions (as verified by the associated EUPS stub packages) of numpy, astropy, scipy, and matplotlib to match the versions of these packages used by Jenkins and the current versions of lsstsw and newinstall.sh (merged 2 months ago as part of DM-14011 and announced here).

I have also updated the flake8 baseline to use 3.6.0 (with associated update of pycodestyle). You will see that W504 has been added to some packages yesterday (enforcing our style of breaking a line after a binary operator) and we are now more strict about the use of backslash escapes in normal (non-raw) python strings.

If you are still using an older conda baseline you will need to upgrade it since numpy1.14 is not binary compatible with v1.13. See my previous instructions on updating for details.


(Krzysztof Findeisen) #2

Sorry, can you clarify the situation with W504? I thought we broke lines before operators, as suggested by PEP8; our own style guide does not elaborate.


(Tim Jenness) #3

About 50% of the fixes I had to make to get this working were to ignore W504. It seems that all our code has been breaking after the operators and the examples in the dev guide use that scheme. PEP8 is ambivalent about it and asks for consistency, whilst suggesting that new code follows Knuth and breaks before the operator. If we wanted to switch to that approach (which seems to be pycodestyles default now via W503) then it wouldn’t be much work to change the code over. After looking at a lot of this code yesterday I think I prefer the look of code that splits before the operator.

I did try to “fix” code that used + as a continuation character to join two fixed strings.

I think we’d need an RFC to change our guide to be more explicit about it but I’d definitely vote for it (as I think would @jbosch).


(Krzysztof Findeisen) #4

:+1: for an RFC; strictly speaking we need one anyway to add new flake8 ignores to Section 1.


(Tim Jenness) #5

I don’t think so since this was already the established style and I’m not proposing a change in our style guide resulting in ignoring W504 (just documenting that this is what we already do). I have a PR open on the dev guide for this.