Refactor python recipes and update python2's to version 2.7.15 (fixed history) #1534

opacam · 2018-12-17T00:58:30Z

Originally started in pr #1460 (moved here to solve the history conflicts)

This pr is intended to complement the amazing work of @inclement in his python3's recipe #1412. It refactors the python3's recipe into the recipe module and updates the python2 version to 2.7.15 using the same build process than the refactored python3's recipe. So, python2 and python3 will share the same build system and allow us to remove some specific source code for python2. Right now the build process completed successfully for both python versions and the python3 recipe also works as expected when installed on android devices...so...

Things to do:

Things to do, probably better to do it apart:

Check/fix if image related recipes are working: libjpeg, libpng and pillow
Fix pygame using the old python recipe or remove it

@inclement

To make it use as a base class for hostpython2 and hostpython3 recipes in a near future. Refactor python3's recipe into a new base class GuestPythonRecipe To make it use as a base class for python2 and python3 recipes in a near future. Move hostpython2 and python2 recipes to a new name hostpython2legacy and python2legacy. This recipes will be useless until properly fixed or maybe it will be removed... Add the new hostpython2/python2 recipes (v2.7.15) Those new recipes will use the same build method than python3. Also added a set of patches, some of them are enabled by default because they are necessary to perform a successful build. The others are added because maybe we will need them. Adapt sdl2's stuff to the new python2's build system Adapt pythonforandroid's core files to the new python2's build system Cause we share the same build system for python2 and python3 recipes, we can safely remove some specific python2's code in favour of the python3's code, otherwise we will surely find troubles in our builds. Adapt python2's test apps to the new python2's build system The python2's test with openssl and sqlite it will probably success, but without the libs until those are enabled. The pygame's test app will fail until properly fixed. Enable sqlite support for python recipes Add ability to compile recipes with clang The android ndk has been migrated his default compiler from gcc to clang and soon will be removed from the ndk. Here we prepare p4a to compile recipes with clang, which will allow us to successfully compile an updated openssl libs. Without this openssl upgrade we will not be able to grant support to python3's _ssl.so module. Note: The default p4a compiler still is gcc...so...no changes on the compile behaviour unless explicitly requested References: kivy#1478 Update OpenSSL to 1.1.1 (uses clang for compilation) This openssl version is an LTS, supported until 11th September 2023. Important: There is now a distinction between the version we use for downloading, and the version used for creating the library: OpenSSL 1.1 now have prefix with "1.1.so". This explains why others recipes that depends on it require the "library" version. Those recipes, still not are modified to support the new version. References: kivy#1478 Enhance openssl recipe and remove lib_version Several actions done: - The openssl recipe has been enhanced by introducing a couple of methods (include_flags and link_flags) which should help us to link other recipes with the openssl libs. - Remove lib_version introduced in the last openssl version update, so we don't have to modify all dependant recipes - Add a new variable `url_version`, used to download our recipe in the subclassed method versioned_url (this replaces the removed lib_version) - Add D__ANDROID_API__ to the configure command (needed to successfully build the libraries and link them with python) - Add documentation Enable openssl support for python recipes This commit grants openssl support for both python versions (2 and 3). The python2 recipe needs some extra work to make it link with python, we need to patch the setup.py file in order to that the python's build system recognises the libraries. This is not the case for the python3 recipe which works like a charm, except for the fact that we have to modify our static class variable ` config_args ` for the python's recipe, i found this to be necessary in my tests, otherwise the openssl libs aren't detected. Fix hardcoded python2 entry for Arch Fix hardcoded python2 entries for BootstrapNDKRecipes Fix numpy's recipe and adds python3's compatibility. Also: - add numpy to CI tests for python3: this module is some kind of special and probably a dependency for a lot of python packages so better make sure that we not break anything...as we already do with python2 - Add numpy to python2 and python3 test apps, cause already have some buttons that allows to test it from the running app. Fix duplicated key in options for python2 test Add python3 test for sqlite and openssl and add python3's compatibility to dependant recipes To be able to run successfully the new test we must add python3 compatibility to some recipes that is why we touch them here. Make that travis test python3 with sqlite3 and openssl Update android ndk to r17c, add missing dependency and update documentation To successfully build the python3 recipe with ctypes we needs an extra dependency in our docker file (libffi-dev) Move gradle stuff from sdl2 to bootstraps/common To make use of it on non sdl2 bootstraps when those are adapted to be gradle compatible Create service_only bootstrap's files structure to be gradle compatible This requires to move some files to a new location, but the files remain untouched for now. Adapt service_only's bootstrap c/java code to new python build system Also add some files because we need it because of the changes made in PythonService.java. Those files add the classes PythonActivity, AssetExtract and ResourceManager (those two lasts are pure copies from the ones in sdl2 bootstrap). Note: All this work is based on previous work done on sdl2 bootstrap Adapt service_only's bootstrap to new python/gradle build system and enables some missing features Note: Some files has been removed because we will use the generic ones of bootstraps/common Add a test app for service_only's bootstrap This is almost a clone from one of @inclement's test apps, with the addition of a function which prints the current date/time. Fix crash for service_only's bootstrap on create_python_bundle When building an apk for service_only's bootstrap using the testapp_service the build suddenly crash, because we don't installed any pure python package, so, the directory "python-install/<distribution directory>" doesn't exist. This makes p4a crash when we tried to enter into this directory. Create webview bootstrap's files structure to be gradle compatible This requires to move some files to a new location, but the files remain untouched for now. Adapt webview's bootstrap c/java code to new python build system Note: All this work is based on previous work done on sdl2 bootstrap Adapt webview's bootstrap to new python/gradle build system and enables some missing features (aars) Note: Some files has been removed because we will use the generic ones of bootstraps/common Make it work webview and service_only bootstraps with the latest python recipes and gradle build Enable python3's compatibility to bootstraps webview and service_only Add travis test for bootstraps webview and service_only In order to avoid errors while running too many parallel tests we remove the basic python2 and python3 tests (because we already test them in his equivalent with the libraries) and the new added tests will only be performed for one python version: - webview: python3 - service_only: python2 Also, to not loose the numpy tests, we enforce to build the numpy recipe in the tests for webview and service_only bootstraps, so we will test it for both python versions. Improve the libraries loading mechanism when initializing the apk The old libraries loading mechanism, has become inefficient because, over the years, more library recipes has been added to p4a project as well as more python versions. So...here we introduce a new mechanism which creates a file with the needed libraries, which will be read at runtime and load the libraries defined in there, so we avoid checking each library against a pattern as the old method. This new mechanism is still incomplete, because still lacks most of the libraries, but has the same functionality, because all the basic libraries used in the old loading mechanism are inside the new mechanism, plus some others which where not handled before like the shared stl libs. With this new mechanism we will have the advantage that will be a lot easier to add the necessary libraries for all the bootstraps at once. Fix libtorrent+boost (update to latest versions and add python3 compatibility) Since the openssl and ndk update the boost and libtorrent recipes weren't working. The old version for boost libraries does not support openssl 1.1, so we must update it. The old libtorrent recipe is strongly dependant on boost so we also update it. Also, before this commit, the compiler used to make those builds were gcc, now we use clang (the default compiler for the latest android ndk). Note: We use the latest release candidate version for libtorrent because still not released the final version (and it is more prepared to be build with clang compiler). To make it work with python3 we need to apply a patch to it, which will be not necessary when released the final version (the changes made by this patch are already merged into libtorrent's master branch). Those recipes were tested for both python versions with a slight modification of the test apps and importing the libtorrent at runtime without problems, plus the generated libraries are linked with our versions of openssl and python (using the readelf command). Fix openssl dependant recipe: cryptography+cffi Since the recent openssl upgrade this recipe stopped to work. Here we adapt the recipe to the new build circumstances and we also fix the cffi recipe because it is a direct dependency of cryptography and had the wrong flags for the new python2 build system. Update cryptography recipe and grants python3 support In order to not have troubles with python3 we update most of the dependant recipes to the latest available versions. Fix openssl dependant recipe: pycrypto (and grants python3 compatibility) Since the recent openssl upgrade this recipe stopped to work. Here we adapt the recipe to the new python2 build system and to new openssl version. Also bump the recipe version number to the latest available (to avoid possible errors with our python3). Fix openssl dependant recipe: scrypt (and grants python3 compatibility) Because since the python/openssl build system changed this recipe stopped to work. Add a testapp for cryptography recipes We add libtorrent recipe into the testapp_encryption because it can be built with our openssl recipe. The ffmpeg recipe it is not included here for multiple reasons: - because depends on a lot of libs (the codecs) - because we included the libtorrent recipe that takes takes a lot of time to be build and the ffmpeg recipe also needs a lot of time Remove hardcoded python2 flags for zbar recipe The python headers are set in the method get_recipe_env of PythonRecipe's base class, so there is no need to set the python headers. Add pyzbar recipe, remove duplicated flags for libzbar and make sure that the library gets loaded at runtime The libzbar recipe contains some flags already set in base class method of get_recipe_env, so removed. Also grants python3 compatibility for libzbar because, despite that the zbar recipe isn't compatible with python3 (the project is stucked in python2 plus it seems unmaintained)...but there are alternatives which can replace it, so we add the pyzbar recipe which works for both versions of python so python3 will have an equivalent to the python2's zbar. Remove unneeded flags and grants python3 compatibility for the apsw recipe The flags that we remove are already set in base class, so no need to set in here. Remove unneeded flags, update version and grants python3 compatibility for the netifaces recipe The flags that we remove are already set in base class, so no need to set in here. Remove hardcoded python2 flags, shorten ldflags and grants python3 compatibility for the pymunk recipe Update protobuf_cpp recipe and grant python3 compatibility The removed flags are already set in base class, so no need to set in here. Update M2Crypto recipe and grant python3 compatibility Also remove unneeded flags because already set in base class Grant python3 compatibility for PyCryptoDome recipe Fix hardcoded/unneeded flags for pysha3 recipe and grant python3 compatibility Enhance the encryption test app with new tests Also refactor part of the source code using the new class TestImport Add ci tests for encryption recipes The M2Crypto python module depends on `swig` during compilation, so we must add it to our docker images to prevent tests errors. Change docker image from ubuntu to debian stretch for the python3 build and make it the default for ci tests Multiple reasons for that...because: - the debian image allow us to select the python version that we want..so we select the same version that we use in our builds and that will allow us to successfully pass the ci test for the webview bootstrap (the problematic recipe is flask) - the debian image is smaller than the ubuntu - the default python3 version for ubuntu is 3.6 and we need 3.7 - we don't need any special feature from ubuntu so debian is fine (probably it's a better choice, because ubuntu relies on debian...) Suppress almost all logs for ci builds (fix travis limit of 4mb of logs) In order to not exceed the travis limitation of 4MB of logs...this will allow us to add more tests without facing this limitation or update the android build tools. It must be said that if any error happens the last 1000 lines of the log will be printed, so we know where is the problem. This will have the advantage that we will focus the problem more quickly but it maybe some cases where the error happens before of the printed lines...if that is the case we should disable temporary this feature, probably with some tests, and rerun the travis tests to get the full log. Add ability to hide some log messages and hide the unpack logs This should allow us to reduce console output when decompressing files (most of the times we don't need that list) and also will reduce the probabilities that travis fails due to the 4mb logs limit. This will fix the travis error when uncompress "the boost recipe" files, which has a lot of files and overpass the travis log limit.

pythonforandroid/bootstrap.py

ghost · 2018-12-17T02:09:39Z

Ok, I have some nitpicks:

the list that need C++ or C shared stdlib linked in are hardcoded. I think that should be set in the recipe instead (see my comment)
some .java files seem to be copied into each separate bootstrap that kinda look like they actually should be in common instead (please note you can have a file in common and still override it by also adding it to a single bootstrap - so there's no need to copy it separately into all bootstraps if just one of them needs a different version)
EDIT: and also, the additions to the .travis.yml seem well-intentioned, but it might be better to keep travis limited to absolutely vital tests due to the exploding testing time otherwise. I think something like .travis.yml.unused or .travis.yml.disabled might be a better place, so the new tests are around if needed but not enabled for now

But in overall, at least from the central changes I checked (I didn't look much into the changed/new recipes, only the central build handling), this all looks like considerable improvements. I didn't test run it, but I like what I'm seeing.

I'm therefore in favor of merging this relatively quickly and improving things later if necessary, because it'd be sad to see all this work buried in another pile of conflicts 👍

By removing some secondary tests we will improve the overall build timings. We mostly test python3, which will be the new standard in a near future and we only tests the basic python2 test with the libs. With all this changes we will end up with 5 jobs.

opacam · 2018-12-17T13:04:13Z

@Jonast, all done...probably more refactoring could be done for the java files, but at least the new files that I introduced are refactored. Also reduced some tests, maybe should be reduced even more...now we will have 5 jobs (I think that is the limit). For you to know, the most stressant recipe is libtorrent+boost...by removing libtorrent we would improve even more the build timings...

ghost · 2018-12-17T20:22:52Z

@opacam we're just discussing this in chat and a problem is that it is so large. But we should still get at least the core of this work in quick to avoid more conflicts.

Could you possibly take out all the new recipes that aren't really needed (libtorrent, boost, all that) to bring the size of the changes down a bit? Are there other things that aren't strictly needed for the core bootstrap + hostpython + new stl linking mechanism which you could take out for now, and make a separate pull request later? (only things that wouldn't require huge code changes if left out to make the core part still work)

Sorry to ask for more changes, but a merge of this size also has certain risks and will delay merging of the awesome core work

AndreMiras · 2018-12-17T20:35:35Z

.travis.yml

@@ -18,11 +18,14 @@ env:
    - ANDROID_SDK_HOME=/opt/android/android-sdk
    - ANDROID_NDK_HOME=/opt/android/android-ndk
  matrix:
-    - COMMAND='. venv/bin/activate && cd testapps/ && python setup_testapp_python3.py apk --sdk-dir $ANDROID_SDK_HOME --ndk-dir $ANDROID_NDK_HOME --requirements sdl2,pyjnius,kivy,python3'
+    # test encryption recipes
+    - COMMAND='. venv/bin/activate && cd testapps/ && python setup_testapp_python_encryption.py apk --dist-name bdisttest_python3_encryption --sdk-dir $ANDROID_SDK_HOME --ndk-dir $ANDROID_NDK_HOME --requirements python3,libffi,openssl,sdl2,pyjnius,kivy,cryptography,pycrypto,scrypt,m2crypto,pysha3,pycryptodome,libtorrent'


I would not build all as we're trying to make trade off between build time and "recipe criticality".
Some of these recipes are not that critical to always have to be built, e.g. libtorrent and few other being listed here.
We still have some kinda of coverage however thanks to the ./ci/rebuild_updated_recipes.py script.

AndreMiras · 2018-12-17T20:37:11Z

.travis.yml

+  - while sleep 1m; do echo "=====[ $SECONDS seconds, tests still building... ]====="; done & PING_LOOP2_PID=$!
+  - docker run p4a /bin/sh -c "$COMMAND" > tests.log 2>&1
+  - kill ${PING_LOOP2_PID}
+  - echo "All operations performed...last build log lines are:" & tail -500 tests.log


I would rather try to avoid all these "ping-hacks" when it's possible.
If we need them sometimes it might that we're misusing the CI.
Even though I agree Travis is pretty limited sometimes

AndreMiras · 2018-12-17T20:37:42Z

.travis.yml.unused

+
+# test service only bootstrap (plus numpy)
+- COMMAND='. venv/bin/activate && cd testapps/ && python setup_testapp_service.py apk --dist-name bdisttest_python3_service --sdk-dir $ANDROID_SDK_HOME --ndk-dir $ANDROID_NDK_HOME --requirements python3,genericndkbuild,numpy'
+- COMMAND='. venv/bin/activate && cd testapps/ && python setup_testapp_service.py apk --dist-name bdisttest_python2_service --sdk-dir $ANDROID_SDK_HOME --ndk-dir $ANDROID_NDK_HOME --requirements python2,genericndkbuild,numpy'


then I would drop this file if it's not used

AndreMiras · 2018-12-17T20:38:53Z

Dockerfile.py2

@@ -26,7 +26,7 @@ RUN apt -y update -qq \


 ENV ANDROID_NDK_HOME="${ANDROID_HOME}/android-ndk"
-ENV ANDROID_NDK_VERSION="16b"
+ENV ANDROID_NDK_VERSION="17c"


doesn't this kind of change already deserve it's own PR for instance?
That why it's easier to justify why it's needed and eventually make it early (or not) to the tree

AndreMiras · 2018-12-17T20:42:26Z

Dockerfile.py3

@@ -15,7 +15,7 @@
 #     Use 'docker run' without '--rm' flag for keeping the container and use
 #     'docker commit <container hash> <new image>' to extend the original image

-FROM ubuntu:18.04
+FROM python:3.7-stretch


I've always been puzzled about base image not clearly coming from a well known distrib and stuff.
What I mean here, is even though the Ubuntu base image is larger than some other ones, it makes it explicit the project compiles/run fine on Ubuntu.
Of course if changing the base image make a 50% time gain, then it can be discussed/justified. If it's a 10% then I'm not sure personally.
So this kinda of change also could be or not hard to make it to master sometimes even as single PR.
It deserves to be discussed, but I would rather have it on a dedicated PR since it could start some long discussions.

good catch. I'm also in favor of sticking to the ubuntu base image, simply because it has a more widely known configuration

AndreMiras · 2018-12-17T20:43:52Z

Dockerfile.py3

@@ -104,7 +104,7 @@ RUN dpkg --add-architecture i386 \
 # specific recipes dependencies (e.g. libffi requires autoreconf binary)
 RUN apt -y update -qq \
    && apt -y install -qq --no-install-recommends \
-        autoconf automake cmake gettext libltdl-dev libtool pkg-config \
+        libffi-dev autoconf automake cmake gettext libltdl-dev libtool pkg-config \


I'm still not sure if we want by design to pickup the recipes or the system lib. Since the recipe could also be installed on host. I don't know what's the orinal plan for p4a and libffi.

AndreMiras · 2018-12-17T20:47:28Z

pythonforandroid/archs.py

@@ -30,13 +30,24 @@ def include_dirs(self):
                d.format(arch=self))
            for d in self.ctx.include_dirs]

-    def get_env(self, with_flags_in_cc=True):
+    def get_env(self, with_flags_in_cc=True, clang=False):


So basically that file change mainly makes it possible to compile with clang.
That's very interesting and probably deserves a PR on its own to make it faster to the tree

AndreMiras · 2018-12-17T21:42:08Z

pythonforandroid/bootstrap.py

+        if 'libiconv' in self.ctx.recipe_build_order:
+            libs_to_load.append('iconv')
+        if 'libzbar' in self.ctx.recipe_build_order:
+            libs_to_load.append('zbar')


It feels kinda weird to have these specific use cases in a core module rather than in a dedicated recipe. What do you think?

AndreMiras · 2018-12-17T21:44:22Z

pythonforandroid/bootstrap.py

+        filens = shprint(sh.find, join(self.dist_dir, '_python_bundle',
+                                       '_python_bundle', 'modules'),
+                         join(self.dist_dir, 'libs'),
+                         '-iname', '*.so', _env=env).stdout.decode('utf-8')


here the logic is unified for both python2 and else and that works? Then that's actually is a good thing and might be something we want to isolate/demonstrate in a dedicated PR

AndreMiras · 2018-12-17T21:45:45Z

pythonforandroid/bootstraps/common/build/build.py

-    if get_bootstrap_name() == "sdl2":
-        args.add_activity = args.add_activity or []
-        args.activity_launch_mode = args.activity_launch_mode or ''
+    # if get_bootstrap_name() == "sdl2":


minor: why is this commented rather than deleted?

AndreMiras · 2018-12-17T21:57:13Z

pythonforandroid/bootstraps/common/build/gradlew.bat

+:mainEnd
+if "%OS%"=="Windows_NT" endlocal
+
+:omega


I cannot grasp why this file was entirely changed? I saw the git mv from sdl2 to common, but I don't get why the whole file is "diff-ed". Is it because of line ending?

AndreMiras · 2018-12-17T22:04:45Z

pythonforandroid/bootstraps/service_only/build/src/main/java/org/kamranzafar/jtar/Octal.java

+        return offset + length;
+    }
+
+}


Also curious why this file and other java files are diffing so much. Is it a github glitch or something else happened here? Or it's something I'm missing?

AndreMiras · 2018-12-17T22:10:46Z

pythonforandroid/bootstraps/webview/build/src/main/java/org/kivy/android/PythonService.java

@@ -12,7 +12,9 @@
 import android.app.Notification;
 import android.app.PendingIntent;
 import android.os.Process;
+import java.io.File;


Minor: why is this import for?

AndreMiras · 2018-12-17T22:12:16Z

pythonforandroid/bootstraps/webview/build/templates/strings.tmpl.xml

@@ -1,5 +1,5 @@
 <?xml version="1.0" encoding="utf-8"?>
 <resources>
    <string name="app_name">{{ args.name }}</string>
-    <string name="private_version">0.1</string>
+    <string name="private_version">{{ private_version }}</string>


Is this something we were missing?
It may deserve it's own PR then

AndreMiras · 2018-12-17T22:13:19Z

pythonforandroid/logger.py

            else:
                logger.debug(''.join(['\t', line.rstrip()]))
+            n_line += 1
        if need_closing_newline:
            stdout.write('{}\r{:>{width}}\r'.format(
                Err_Style.RESET_ALL, ' ', width=(columns - 1)))


Definitely deserves to be discussed in its own PR

AndreMiras · 2018-12-17T22:39:47Z

Kudos for that amazing PR, the amount of work is just insane! Thank you for all your follow-up efforts.
Unfortunately the PR is too big for my human brain to process as I'm more used to break down problems into smaller pieces.
I left some random comment here and there. But there's so much code involved that I don't know where to start reviewing, what to comment.... I personally think breaking down PR usually make them faster to the tree.
This is 200+ files of diff and while walking through it I felt like it could be "easily" be broken down into ~10 PR.
For instance I would totally take some recipes out of it even it it means leaving them broken. Random example, the idna recipe update that has a version bump and python3 added to the depends doesn't necessarily need to be in that PR. That just a random trivial example, but I would pretty much generalise it for other recipes as well.
I have a lot more things to share or ask about that PR, but it would probably not be so productive to write a massive comment about it and not convenient for you to tackle my comments/questions in another huge reply.
I hope you don't get me wrong. I love to see contributions especially the ones that require such level of knowledge to improve the core deeply like you did. But we really need to find a more workable way to understand/test and integrate changes and I believe it's by doing smaller increments.

opacam · 2018-12-18T09:59:04Z

Ok guys, don't worries, all the heavy job is done so split into small pieces should not be a problem, basically because when I did all this stuff I tried to follow a temporal line and I tried to group the parts, so it could be easily followed, all of that were lost at the moment of squashing...so reviewing all this changes here is not a good idea, let's do it the right way.

I also didn't realize that this will ended up with soo many changes...anyway...all the work until now has allowed us to see that this works and it was necessary to properly test some parts. Saying that, I already pushed a new pr with only the core of the python refactoring, still huge (about the half of all the stuff...more or less), but hope that more manageable. The next part should be the bootstraps fixes, this also will be big but not as big as the core part. All the other stuff shouldn't be a problem. By the way, all the changes related with supressing the output of ci tests were necessary to pass the bootstrap tests and the encryption test, cause this tests will not be enabled in travis, we can omit all of that.

ghost reviewed Dec 17, 2018

View reviewed changes

pythonforandroid/bootstrap.py Outdated Show resolved Hide resolved

opacam added 5 commits December 17, 2018 11:45

Enhance stl dependency management (remove hardcoded recipes entries)

37844f2

Unify PythonUtil.java

4d5ffbb

Unify AssetExtract.java

a742c1e

Unify ResourceManager.java

e0f2ff6

Improve travis build timings

c1125dc

By removing some secondary tests we will improve the overall build timings. We mostly test python3, which will be the new standard in a near future and we only tests the basic python2 test with the libs. With all this changes we will end up with 5 jobs.

opacam mentioned this pull request Dec 17, 2018

[WIP] Refactor python recipes and update python2's to version 2.7.15 #1460

Closed

17 tasks

Update documentation about the new python unified recipes

fbdee31

opacam changed the title ~~[WIP] HISTORY OF: Refactor python recipes and update python2's to version 2.7.15~~ Refactor python recipes and update python2's to version 2.7.15 (fixed history) Dec 17, 2018

AndreMiras reviewed Dec 17, 2018

View reviewed changes

opacam mentioned this pull request Dec 18, 2018

[CORE UPDATE - PART I] Refactor python recipes + openssl + sqlite3 #1537

Merged

6 tasks

opacam closed this Dec 18, 2018

opacam deleted the python-2.7.15-squashed branch June 15, 2019 11:35

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Refactor python recipes and update python2's to version 2.7.15 (fixed history) #1534

Refactor python recipes and update python2's to version 2.7.15 (fixed history) #1534

opacam commented Dec 17, 2018 •

edited

Loading

ghost commented Dec 17, 2018 •

edited by ghost

Loading

opacam commented Dec 17, 2018

ghost commented Dec 17, 2018 •

edited by ghost

Loading

AndreMiras Dec 17, 2018

AndreMiras Dec 17, 2018

AndreMiras Dec 17, 2018

AndreMiras Dec 17, 2018

AndreMiras Dec 17, 2018

ghost Dec 17, 2018

AndreMiras Dec 17, 2018

AndreMiras Dec 17, 2018

AndreMiras Dec 17, 2018

AndreMiras Dec 17, 2018

AndreMiras Dec 17, 2018

AndreMiras Dec 17, 2018

AndreMiras Dec 17, 2018

AndreMiras Dec 17, 2018

AndreMiras Dec 17, 2018

AndreMiras Dec 17, 2018

AndreMiras commented Dec 17, 2018

opacam commented Dec 18, 2018

Refactor python recipes and update python2's to version 2.7.15 (fixed history) #1534

Refactor python recipes and update python2's to version 2.7.15 (fixed history) #1534

Conversation

opacam commented Dec 17, 2018 • edited Loading

ghost commented Dec 17, 2018 • edited by ghost Loading

opacam commented Dec 17, 2018

ghost commented Dec 17, 2018 • edited by ghost Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

AndreMiras commented Dec 17, 2018

opacam commented Dec 18, 2018

opacam commented Dec 17, 2018 •

edited

Loading

ghost commented Dec 17, 2018 •

edited by ghost

Loading

ghost commented Dec 17, 2018 •

edited by ghost

Loading