Consider lowing Python version requirements

[neersighted]

Hey, I recently attempted to use pipx on a Debian stretch system, which is still on Python 3.5.
As such, Python 3.5 support would be nice to have in pipx. As far as I can tell, the only feature that requires 3.6 that pipx requires is PEP 498 (literal string interpolation).

Would you be willing to use string.format() over PEP 498 strings?

[cs01]

Is it possible to bump your Debian machine to have a later version of Python? At this time I am not really interested in supporting versions older than Python 3.6. If we go down that route then we can never go back, and I really love f-strings.

[neersighted]

It's not so much a matter of the machine (I can of course install my own python into $HOME), but that Debian stretch will be supported for one to two more years, at least, and is frozen at 3.5 (as is Ubuntu < 18.04).

I don't think it's unreasonable to bump the requirement when major distributions (outside CentOS/RHEL, which will, of course, lag behind) uniformly ship Python 3.6.

Additionally, my PR contains some bugfixes (once case of emoji ignoring the global config) and minor improvements (logging should use %s-style formatting, explicit single quotes instead of repr()); though these can of course be split out into a new PR if desired.

[cs01]

I am conflicted on this one. You make a good point about it being shipped and supported for another couple years. But I really do prefer f-strings, and I have seen other projects requiring 3.6+ (notably black). I am leaning toward keeping this 3.6+, but perhaps will change my mind if pipx becomes more widely used and gets high demand for 3.5.

Thank you for that PR btw. I intentionally used f-string formatting in logging after seeing a post at work about how performance was (surprisingly) slightly faster using f-strings rather than %s, and of course is easier to read and write, and consistent with the rest of the codebase.

[neersighted]

You make a fair point as well. I'll consider this resolved then, but I do request you look over my PR and pull in improvements where appropriate. Let me know if you don't have the time to do so, and I'll see if I can resubmit it preserving f-strings at some point.

[cs01]

pull in improvements where appropriate

Do you mean manually pull them in since the f-strings will be left in? And how do you feel about leaving the logger calls as f-strings? If those all remain, all that is left is the repr change (I think). In that case I would prefer an updated PR since I would only want to merge that change. LMK if I missed any other changes. EDIT: I just remembered you also caught an emoji bug. Updating to just the minimal set of changes I want to merge will be great, and I can approve it.

[neersighted]

Yeah, I was talking about removing usage of repr() and str(), as well as the emoji fix. I can try to get around to the updated PR, but it might take a while.

[leonsmith]

I had just been thinking about this, another potential solution is changing the language?

This starts to become super useful when it's not tied to a specific python version... Could be ported to bash? Or a be a compiled binary with go? you also get around the chicken and egg problem of having a bootstrapper?

I'm convinced it's such a good idea I might start having a play around with proof of concepts this coming week

[cs01]

pipsi exists and works down to 2.7. There is no reason pipx couldn't be written to support 2.7. I just don't want to because 2.7 is going to be dead soon and 3.6+ has f-strings and pathlib.

Something else to consider is that if a different language is used, the virtualenv/venv difference is still there between Python 2/3 so you'll still have to do Python version detection.

Regardless of what language is used, a way to install pipx (a bootstrapper) is still needed -- whether that's a bash script, go binary, haskell binary, or Python script, something needs to do the initial pipx installation. Since pipx is built to run Python binaries, it's safe to assume the system has Python on it, so it makes sense to me to just use Python. Using a compiled binary means you need to build binaries for every OS.

[kwbr]

Support for older Python version to install pipx would be very helpful for those of us locked on older Python versions

[cs01]

Thank you for your interest, but I am going to close this because, although useful to a small group of people, the additional maintenance burden to the pipx project would not be worth it.