Configure GitHub actions

[mitar]

It seems that linting fails a lot, so I commented it out for now.

Publishing has not been tested.

[mitar]

This is how it looks: https://github.com/mitar/pytypes/actions/runs/1301382858

[mitar]

So it seems Python 3.9 again breaks this library and would require additional changes for tests to pass. It would be great to get full support for 3.8 in soon, though.

[Stewori]

Thanks for looking into this! It's no surprise that 3.9+ break it again as there were significant changes to typing. My plan is to call the next release "pytypes 1.0", no beta any more. Not because it actually surpassed beta state, but because I think development should continue with major version increased to 2.0. This allows a major break. 2.x will require Python 3.9+ and have support for earlier versions only by coincidence. 1.x will be the way to go for legacy support up to 3.8. More on those plans later.

[Stewori]

Consequently, that means 3.9 should be removed from the 1.0 branch test config.

[Stewori]

Do you happen to know whether github-actions offers something similar to Travis' automatic PyPI deployment feature? (see https://github.com/Stewori/pytypes/blob/master/.travis.yml#L18)

[mitar]

This allows a major break. 2.x will require Python 3.9+ and have support for earlier versions only by coincidence. 1.x will be the way to go for legacy support up to 3.8. More on those plans later.

Looking forward to this! This package is really great!

My plan is to call the next release "pytypes 1.0", no beta any more.

I am looking forward to this, too. :-)

Consequently, that means 3.9 should be removed from the 1.0 branch test config.

Sure.

What about linting? I commented it out.

Do you happen to know whether github-actions offers something similar to Travis' automatic PyPI deployment feature?

Yes, I already put it in there. See here.

But I have not tested it.

[Stewori]

What about linting? I commented it out.

Good choice. Fixing that is a no-goal for the next release. Maybe in the 2.0 branch, it depends.

I suspect many linting issues originate in my intentional divergence from PEP 8 in two aspects:

• I favor longer line width because nowadays screens are so wide. IIRC pytypes' code largely obeys a line width of 100 but PEP 8 wants something like 80.
• I use Java-style when line-breaking function defs, i.e.

def blah(arg1, arg2, arg3, arg4,
[two indents]arg5, arg6)

PEP 8 instead wants either

def blah(arg1, arg2, arg3, arg4,
         arg5, arg6) # align with opening brace (possibly not a multitude of indentation)

or

def blah(
[some indentation]arg1, arg2, arg3, arg4,
[some indentation]arg5, arg6)

The first version does not work for me because I prefer working with tabs. On check in and check out I apply a script that auto-converts to tabs and back. This breaks or at least has an ugly result if an inset cannot be expressed in indentations. The second version I find unnecessarily spacy. If lint can be configured to align with these choices we can revisit it in future.

[mitar]

I favor longer line width because nowadays screens are so wide. IIRC pytypes' code largely obeys a line width of 100 but PEP 8 wants something like 80.

That is just a matter of setting of the linter. I have not seen any which would not support this. It is pretty common to allow longer lines.

I use:

def blah(
[some indentation]arg1, arg2, arg3, arg4,
[some indentation]arg5, arg6,
):

If lint can be configured to align with these choices we can revisit it in future.

I think these days Python is moving into the direction of go where there is simply standard formatter. So you do not lint anymore, you just format the code and move on. Why complain if tool can just fix it for you. The defacto standard is black. I learned from both black and go that it is much better to simply use the tool even if it is not "perfect" style, you get used to it and then it is just easier for everyone involved. And it also takes the least amount of time to use it.

So my proposal would be to run black on the codebase, commit it. And then move on with your life.

[Stewori]

Thanks for the pointer; I will give it a thought to use it for the 2.0 branch. For 1.0 we'll leave linting turned off.

[Stewori]

Re publishing:

I would believe that somewhere the key https://github.com/Stewori/pytypes/blob/master/.travis.yml#L22 should be stored. I guess it should go somewhere here: https://github.com/Stewori/pytypes/pull/105/files#diff-092659a9bd0068791326fb1d08f005532e5aeb983b999a7bd32c51deee0a71d5R47 The comments there refer to the project setup. Do you known what that means, what I need to configure to make it work?

[mitar]

You configure that here: https://github.com/Stewori/pytypes/settings/secrets/actions The value is then passed to the action.