You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
cherry_picker.py uses f-strings and requires Python 3.6. Is this absolutely necessary? The version of Python shipped with Ubuntu LTS (and perhaps other popular distributions) is 3.5.
No, this is not a blocker to me. This shouldn't be large problem since when you use cherry_picker.py you should have built and tested Python in the master branch. But on other hand, when you use just built executable and checkout other branch this can cause problems because py-files in Lib/ no longer match the version of the executable. It would be better to use the system Python.
Have a separate checkout for doing the cherry-picking from the interpreter you are using to execute cherry_picker.py (e.g. either a pristine checkout or the one you did the fix in that you pushed upstream; I think git workingtree helps with this)
Install Python 3.6.0 manually so you have a permanent install
Remove f-strings and add compatibility for Python 3.5
I personally do option 2 although I have done option 1 in the past.
Fedora has multiple runtimes (including 3.6) built as system packages for the benefit of the system python-tox package, so setting up a cpicker venv that uses 3.6 was straightforward for me personally - with the venv active, I get 3.6 when I run python ../core-workflow/cherry_picker/cherry_picker.py ....
Even without a system 3.6 package though, it's possible to do a make altinstall and set up a venv from that with 3.6.x or 3.7.0a0 (I tried making a venv straight from a dev directory, but that confused vex, the venv management utility I use).
I also find it's just plain nice to be able to use the latest features when writing CPython automation tools, and if we assume a venv, we'll be able to consider adding third party dependencies (e.g. @brettcannon's gidgethub library once we start looking at turning this into a fully automated bot)
I should also mention that creating a venv from a checkout build works fine (see how make venv works in Docs/), so vex is making some assumption that a checkout build breaks.
I prefer portable tools that don't require creating separate Python installation, but if this is good for other core developers I can use a workaround.
FWIW, I'd rather have cherry_picker be compatible with recent system Pythons. That includes Python 3.5 or even Python 3.4 on some distributions. I can still install Python 3.6 from Anaconda...
Activity
Mariatta commentedon Mar 20, 2017
Well... while it's not absolutely necessary, I really like f-strings 😅
It is easy enough to convert the script to be compatible with Python 3.5.
Is this a blocker for you (or others) ?
serhiy-storchaka commentedon Mar 20, 2017
No, this is not a blocker to me. This shouldn't be large problem since when you use
cherry_picker.pyyou should have built and tested Python in the master branch. But on other hand, when you use just built executable and checkout other branch this can cause problems because py-files in Lib/ no longer match the version of the executable. It would be better to use the system Python.@ncoghlan, what do you think about this?
brettcannon commentedon Mar 20, 2017
I see three possible solutions to this:
I personally do option 2 although I have done option 1 in the past.
ncoghlan commentedon Mar 21, 2017
Fedora has multiple runtimes (including 3.6) built as system packages for the benefit of the system
python-toxpackage, so setting up acpickervenv that uses 3.6 was straightforward for me personally - with the venv active, I get 3.6 when I runpython ../core-workflow/cherry_picker/cherry_picker.py ....Even without a system 3.6 package though, it's possible to do a
make altinstalland set up a venv from that with 3.6.x or 3.7.0a0 (I tried making a venv straight from a dev directory, but that confusedvex, the venv management utility I use).I also find it's just plain nice to be able to use the latest features when writing CPython automation tools, and if we assume a venv, we'll be able to consider adding third party dependencies (e.g. @brettcannon's gidgethub library once we start looking at turning this into a fully automated bot)
brettcannon commentedon Mar 21, 2017
I should also mention that creating a venv from a checkout build works fine (see how
make venvworks inDocs/), so vex is making some assumption that a checkout build breaks.serhiy-storchaka commentedon Mar 22, 2017
I prefer portable tools that don't require creating separate Python installation, but if this is good for other core developers I can use a workaround.
pitrou commentedon Mar 24, 2017
FWIW, I'd rather have
cherry_pickerbe compatible with recent system Pythons. That includes Python 3.5 or even Python 3.4 on some distributions. I can still install Python 3.6 from Anaconda...doko42 commentedon Jun 7, 2017
+1 on being compatible with system Pythons