Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Backport blackening, pytest to 2.0 #1291
Been frustrated with the difficulty (or the perceived difficulty, hasn't happened a lot here specifically but was a huge problem for a while in Fabric, Invoke) of forward-porting changes through the 2.4.x era pytest and black overhauls. Trying to backport those to 2.0 onwards so we have a nice clean break at 2.0 (this is in part to support dropping 1.x support entirely, which has its own additional barrier to easy maintainership).
Specifically this means taking work for, or around, #1100 and an un-ticketed set of PyCon 2018 sprint changes around implementing
Mostly making this a ticket to help track stuff I needed to tweak or defer.
Got here by basically going "ok where did we start the pytest work" and that seems to be at e8c8f81 so I'm now cherry picking all apparently relevant commits from there up through the work for #1100 (aka 0bf3fa4).
First minor stumbling block is that 385856d results in complaints like so:
This does not appear under eg the 2.4 branch so I'm not sure what's up and am hoping it was a temporary weirdness from using modern import practices with the old
Less of a concern, but still valid, is that downstream processes like third party package maintainers which may run tests or similar, will find this a breaking change (if they're manually invoking
I don't like this, but I don't have time to do some sort of "handles both!" backport process, and those maintainers will need to change sometime anyhow (esp if they are offering 2.4 and up). My own needs to backport stuff w/o worry unfortunately trump most other concerns.
added a commit
Sep 17, 2018
Ah here's a rub, this build proves that I forgot Invoke itself dropped 2.6/3.3 support in 0.22.0.
Technically speaking, I could drop 2.6/3.3 support in the older release lines in the sense that 'we no longer support it', especially if I can drop it purely on the dev/test side and not the install/API side. But that feels kinda shitty. Can I work around this?
Insofar as we're not actually importing the code under test in our Invoke tasks...maybe? Just try using a different Python interpreter for Invoke itself? Would guess Travis doesn't make that possible tho; and it'd cause issues re: dev requirements and the local virtualenv too (tho I guess I could just blast out the dev-requirements into the global system python env...but...ugh. esp given we say
So it seems like the choices are "reimplement the Invoke bits in regular shell in travis.yml" or "remove 2.6/3.3 from the test matrix even back to 2.0":
Real glad I remembered about