-
Notifications
You must be signed in to change notification settings - Fork 98
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Single build for Python 2 and 3 #256
Conversation
I think in case of python 3 you don't want in place build...only build and install |
This makes the files under support/ mostly Python 3, with backward compatibility for Python 2. Changes include - `from __future__ import print_function` and `print(...)` - imports with `ModuleNotFoundError` or `ImportError` catches(*) - `.iteritems()` and `.itervalues()` replacead by `items()` and `values()` (this assumes there are no large dicts involved). - `map` replaced by a list comprehension. - a few specific changes, such as the `func_code` vs. the `__code__` attribute. (*) Which exception is tested for, depends on what is the easiest to test for. `ModuleNotFoundError` should be caught for if the first attempted imports are for Python 2, `ImportError` should be caught for if the attempted imports are for Python 3 instead.
Build parts for 'framework' and a single code are now the same for Python 2 and 3. This does rely more on a hack than proper Python 3 support: because the Python 2 Amuse code code needs to be compiled to Python 3, but not in place (to not mess up the (git) source), the necessary Python files are copied to the temporary build directory, and then compiled. This means that, to actually use the code, one should set their PYTHONPATH to the relevant build directory (this happens automatically when building though, i.e., when using `make <something>.code`). Compared to building all codes at once (support/setup_codes.py/BuildCodes or BuildLibraries), which uses copy_codes_to_build_dir, this copies once, but avoids copying again if a file is already found in the build dir (and presumed compiled for the correct Python version). This work-around can be avoided in the future in two ways: - the core Amuse code is Python 3, and backwards compatible with Python 2. In that case, no copying of files is necessary. - the code Amuse code is its own package, and becomes an essential requirement to install before using the generic Amuse package. In this case, the installation of the core Amuse code will have ensure the code is already compiled for the relevant Python version.
This now provides single build mechanisms for Python 2 and 3. For example, run configure with the relevant Python executable set:
and each of the following works:
At the moment, all Python 2 builds are in-place (as was the default), while all Python 3 builds are out-of-place (to not mess up the git source tree). See also #271 . The work-around for building a single code is similar as for |
Replaced by #273 . |
(do not merge; preview)
This is a preview for a PR for a single build system that works for both Python 2 and Python 3.
This removes the
support3/
directory, and makes the modules insupport/
Python 3, with Python 2 backward compatibility.Build files such as
setup.py
andMakefile
also remove their dependencies onsupport3
.At the moment, many parts are not built (i.e., less parts are built than with the
support3
package), for both Python 2 and 3. There'll be parts I've overlooked in the conversion, but I've put the PR here so people can have a peek.At the moment, during a build, the
2to3
script is run to convert all the Amuse code to Python 3 (so this can be built in-place). This change can afterwards be easily undone withgit checkout -- src
.