2016-05-12 12:22:25 +08:00
|
|
|
##############################################################################
|
2017-09-07 11:44:16 +08:00
|
|
|
# Copyright (c) 2013-2017, Lawrence Livermore National Security, LLC.
|
2016-05-12 12:22:25 +08:00
|
|
|
# Produced at the Lawrence Livermore National Laboratory.
|
|
|
|
#
|
|
|
|
# This file is part of Spack.
|
|
|
|
# Created by Todd Gamblin, tgamblin@llnl.gov, All rights reserved.
|
|
|
|
# LLNL-CODE-647188
|
|
|
|
#
|
|
|
|
# For details, see https://github.com/llnl/spack
|
2017-06-25 13:22:55 +08:00
|
|
|
# Please also see the NOTICE and LICENSE files for our notice and the LGPL.
|
2016-05-12 12:22:25 +08:00
|
|
|
#
|
|
|
|
# This program is free software; you can redistribute it and/or modify
|
|
|
|
# it under the terms of the GNU Lesser General Public License (as
|
|
|
|
# published by the Free Software Foundation) version 2.1, February 1999.
|
|
|
|
#
|
|
|
|
# This program is distributed in the hope that it will be useful, but
|
|
|
|
# WITHOUT ANY WARRANTY; without even the IMPLIED WARRANTY OF
|
|
|
|
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the terms and
|
|
|
|
# conditions of the GNU Lesser General Public License for more details.
|
|
|
|
#
|
|
|
|
# You should have received a copy of the GNU Lesser General Public
|
|
|
|
# License along with this program; if not, write to the Free Software
|
|
|
|
# Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
|
|
|
|
##############################################################################
|
2016-12-08 20:39:10 +08:00
|
|
|
import ast
|
2015-01-11 11:37:01 +08:00
|
|
|
import os
|
Python command, libraries, and headers (#3367)
## Motivation
Python installations are both important and unfortunately inconsistent. Depending on the Python version, OS, and the strength of the Earth's magnetic field when it was installed, the name of the Python executable, directory containing its libraries, library names, and the directory containing its headers can vary drastically.
I originally got into this mess with #3274, where I discovered that Boost could not be built with Python 3 because the executable is called `python3` and we were telling it to use `python`. I got deeper into this mess when I started hacking on #3140, where I discovered just how difficult it is to find the location and name of the Python libraries and headers.
Currently, half of the packages that depend on Python and need to know this information jump through hoops to determine the correct information. The other half are hard-coded to use `python`, `spec['python'].prefix.lib`, and `spec['python'].prefix.include`. Obviously, none of these packages would work for Python 3, and there's no reason to duplicate the effort. The Python package itself should contain all of the information necessary to use it properly. This is in line with the recent work by @alalazo and @davydden with respect to `spec['blas'].libs` and friends.
## Prefix
For most packages in Spack, we assume that the installation directory is `spec['python'].prefix`. This generally works for anything installed with Spack, but gets complicated when we include external packages. Python is a commonly used external package (it needs to be installed just to run Spack). If it was installed with Homebrew, `which python` would return `/usr/local/bin/python`, and most users would erroneously assume that `/usr/local` is the installation directory. If you peruse through #2173, you'll immediately see why this is not the case. Homebrew actually installs Python in `/usr/local/Cellar/python/2.7.12_2` and symlinks the executable to `/usr/local/bin/python`. `PYTHONHOME` (and presumably most things that need to know where Python is installed) needs to be set to the actual installation directory, not `/usr/local`.
Normally I would say, "sounds like user error, make sure to use the real installation directory in your `packages.yaml`". But I think we can make a special case for Python. That's what we decided in #2173 anyway. If we change our minds, I would be more than happy to simplify things.
To solve this problem, I created a `spec['python'].home` attribute that works the same way as `spec['python'].prefix` but queries Python to figure out where it was actually installed. @tgamblin Is there any way to overwrite `spec['python'].prefix`? I think it's currently immutable.
## Command
In general, Python 2 comes with both `python` and `python2` commands, while Python 3 only comes with a `python3` command. But this is up to the OS developers. For example, `/usr/bin/python` on Gentoo is actually Python 3. Worse yet, if someone is using an externally installed Python, all 3 commands may exist in the same directory! Here's what I'm thinking:
If the spec is for Python 3, try searching for the `python3` command.
If the spec is for Python 2, try searching for the `python2` command.
If neither are found, try searching for the `python` command.
## Libraries
Spack installs Python libraries in `spec['python'].prefix.lib`. Except on openSUSE 13, where it installs to `spec['python'].prefix.lib64` (see #2295 and #2253). On my CentOS 6 machine, the Python libraries are installed in `/usr/lib64`. Both need to work.
The libraries themselves change name depending on OS and Python version. For Python 2.7 on macOS, I'm seeing:
```
lib/libpython2.7.dylib
```
For Python 3.6 on CentOS 6, I'm seeing:
```
lib/libpython3.so
lib/libpython3.6m.so.1.0
lib/libpython3.6m.so -> lib/libpython3.6m.so.1.0
```
Notice the `m` after the version number. Yeah, that's a thing.
## Headers
In Python 2.7, I'm seeing:
```
include/python2.7/pyconfig.h
```
In Python 3.6, I'm seeing:
```
include/python3.6m/pyconfig.h
```
It looks like all Python 3 installations have this `m`. Tested with Python 3.2 and 3.6 on macOS and CentOS 6
Spack has really nice support for libraries (`find_libraries` and `LibraryList`), but nothing for headers. Fixed.
2017-04-30 08:24:13 +08:00
|
|
|
import platform
|
2015-01-21 07:07:53 +08:00
|
|
|
import re
|
Python command, libraries, and headers (#3367)
## Motivation
Python installations are both important and unfortunately inconsistent. Depending on the Python version, OS, and the strength of the Earth's magnetic field when it was installed, the name of the Python executable, directory containing its libraries, library names, and the directory containing its headers can vary drastically.
I originally got into this mess with #3274, where I discovered that Boost could not be built with Python 3 because the executable is called `python3` and we were telling it to use `python`. I got deeper into this mess when I started hacking on #3140, where I discovered just how difficult it is to find the location and name of the Python libraries and headers.
Currently, half of the packages that depend on Python and need to know this information jump through hoops to determine the correct information. The other half are hard-coded to use `python`, `spec['python'].prefix.lib`, and `spec['python'].prefix.include`. Obviously, none of these packages would work for Python 3, and there's no reason to duplicate the effort. The Python package itself should contain all of the information necessary to use it properly. This is in line with the recent work by @alalazo and @davydden with respect to `spec['blas'].libs` and friends.
## Prefix
For most packages in Spack, we assume that the installation directory is `spec['python'].prefix`. This generally works for anything installed with Spack, but gets complicated when we include external packages. Python is a commonly used external package (it needs to be installed just to run Spack). If it was installed with Homebrew, `which python` would return `/usr/local/bin/python`, and most users would erroneously assume that `/usr/local` is the installation directory. If you peruse through #2173, you'll immediately see why this is not the case. Homebrew actually installs Python in `/usr/local/Cellar/python/2.7.12_2` and symlinks the executable to `/usr/local/bin/python`. `PYTHONHOME` (and presumably most things that need to know where Python is installed) needs to be set to the actual installation directory, not `/usr/local`.
Normally I would say, "sounds like user error, make sure to use the real installation directory in your `packages.yaml`". But I think we can make a special case for Python. That's what we decided in #2173 anyway. If we change our minds, I would be more than happy to simplify things.
To solve this problem, I created a `spec['python'].home` attribute that works the same way as `spec['python'].prefix` but queries Python to figure out where it was actually installed. @tgamblin Is there any way to overwrite `spec['python'].prefix`? I think it's currently immutable.
## Command
In general, Python 2 comes with both `python` and `python2` commands, while Python 3 only comes with a `python3` command. But this is up to the OS developers. For example, `/usr/bin/python` on Gentoo is actually Python 3. Worse yet, if someone is using an externally installed Python, all 3 commands may exist in the same directory! Here's what I'm thinking:
If the spec is for Python 3, try searching for the `python3` command.
If the spec is for Python 2, try searching for the `python2` command.
If neither are found, try searching for the `python` command.
## Libraries
Spack installs Python libraries in `spec['python'].prefix.lib`. Except on openSUSE 13, where it installs to `spec['python'].prefix.lib64` (see #2295 and #2253). On my CentOS 6 machine, the Python libraries are installed in `/usr/lib64`. Both need to work.
The libraries themselves change name depending on OS and Python version. For Python 2.7 on macOS, I'm seeing:
```
lib/libpython2.7.dylib
```
For Python 3.6 on CentOS 6, I'm seeing:
```
lib/libpython3.so
lib/libpython3.6m.so.1.0
lib/libpython3.6m.so -> lib/libpython3.6m.so.1.0
```
Notice the `m` after the version number. Yeah, that's a thing.
## Headers
In Python 2.7, I'm seeing:
```
include/python2.7/pyconfig.h
```
In Python 3.6, I'm seeing:
```
include/python3.6m/pyconfig.h
```
It looks like all Python 3 installations have this `m`. Tested with Python 3.2 and 3.6 on macOS and CentOS 6
Spack has really nice support for libraries (`find_libraries` and `LibraryList`), but nothing for headers. Fixed.
2017-04-30 08:24:13 +08:00
|
|
|
import sys
|
2015-02-02 22:09:35 +08:00
|
|
|
|
2016-07-23 02:08:08 +08:00
|
|
|
import llnl.util.tty as tty
|
2016-03-18 21:40:53 +08:00
|
|
|
from llnl.util.lang import match_predicate
|
2016-12-09 17:18:10 +08:00
|
|
|
from llnl.util.filesystem import force_remove
|
2017-10-23 20:23:00 +08:00
|
|
|
|
|
|
|
import spack
|
2016-03-18 21:40:53 +08:00
|
|
|
from spack import *
|
Python command, libraries, and headers (#3367)
## Motivation
Python installations are both important and unfortunately inconsistent. Depending on the Python version, OS, and the strength of the Earth's magnetic field when it was installed, the name of the Python executable, directory containing its libraries, library names, and the directory containing its headers can vary drastically.
I originally got into this mess with #3274, where I discovered that Boost could not be built with Python 3 because the executable is called `python3` and we were telling it to use `python`. I got deeper into this mess when I started hacking on #3140, where I discovered just how difficult it is to find the location and name of the Python libraries and headers.
Currently, half of the packages that depend on Python and need to know this information jump through hoops to determine the correct information. The other half are hard-coded to use `python`, `spec['python'].prefix.lib`, and `spec['python'].prefix.include`. Obviously, none of these packages would work for Python 3, and there's no reason to duplicate the effort. The Python package itself should contain all of the information necessary to use it properly. This is in line with the recent work by @alalazo and @davydden with respect to `spec['blas'].libs` and friends.
## Prefix
For most packages in Spack, we assume that the installation directory is `spec['python'].prefix`. This generally works for anything installed with Spack, but gets complicated when we include external packages. Python is a commonly used external package (it needs to be installed just to run Spack). If it was installed with Homebrew, `which python` would return `/usr/local/bin/python`, and most users would erroneously assume that `/usr/local` is the installation directory. If you peruse through #2173, you'll immediately see why this is not the case. Homebrew actually installs Python in `/usr/local/Cellar/python/2.7.12_2` and symlinks the executable to `/usr/local/bin/python`. `PYTHONHOME` (and presumably most things that need to know where Python is installed) needs to be set to the actual installation directory, not `/usr/local`.
Normally I would say, "sounds like user error, make sure to use the real installation directory in your `packages.yaml`". But I think we can make a special case for Python. That's what we decided in #2173 anyway. If we change our minds, I would be more than happy to simplify things.
To solve this problem, I created a `spec['python'].home` attribute that works the same way as `spec['python'].prefix` but queries Python to figure out where it was actually installed. @tgamblin Is there any way to overwrite `spec['python'].prefix`? I think it's currently immutable.
## Command
In general, Python 2 comes with both `python` and `python2` commands, while Python 3 only comes with a `python3` command. But this is up to the OS developers. For example, `/usr/bin/python` on Gentoo is actually Python 3. Worse yet, if someone is using an externally installed Python, all 3 commands may exist in the same directory! Here's what I'm thinking:
If the spec is for Python 3, try searching for the `python3` command.
If the spec is for Python 2, try searching for the `python2` command.
If neither are found, try searching for the `python` command.
## Libraries
Spack installs Python libraries in `spec['python'].prefix.lib`. Except on openSUSE 13, where it installs to `spec['python'].prefix.lib64` (see #2295 and #2253). On my CentOS 6 machine, the Python libraries are installed in `/usr/lib64`. Both need to work.
The libraries themselves change name depending on OS and Python version. For Python 2.7 on macOS, I'm seeing:
```
lib/libpython2.7.dylib
```
For Python 3.6 on CentOS 6, I'm seeing:
```
lib/libpython3.so
lib/libpython3.6m.so.1.0
lib/libpython3.6m.so -> lib/libpython3.6m.so.1.0
```
Notice the `m` after the version number. Yeah, that's a thing.
## Headers
In Python 2.7, I'm seeing:
```
include/python2.7/pyconfig.h
```
In Python 3.6, I'm seeing:
```
include/python3.6m/pyconfig.h
```
It looks like all Python 3 installations have this `m`. Tested with Python 3.2 and 3.6 on macOS and CentOS 6
Spack has really nice support for libraries (`find_libraries` and `LibraryList`), but nothing for headers. Fixed.
2017-04-30 08:24:13 +08:00
|
|
|
from spack.util.prefix import Prefix
|
2016-12-09 17:18:10 +08:00
|
|
|
import spack.util.spack_json as sjson
|
2015-02-09 18:54:49 +08:00
|
|
|
|
2015-01-08 03:48:21 +08:00
|
|
|
|
Python command, libraries, and headers (#3367)
## Motivation
Python installations are both important and unfortunately inconsistent. Depending on the Python version, OS, and the strength of the Earth's magnetic field when it was installed, the name of the Python executable, directory containing its libraries, library names, and the directory containing its headers can vary drastically.
I originally got into this mess with #3274, where I discovered that Boost could not be built with Python 3 because the executable is called `python3` and we were telling it to use `python`. I got deeper into this mess when I started hacking on #3140, where I discovered just how difficult it is to find the location and name of the Python libraries and headers.
Currently, half of the packages that depend on Python and need to know this information jump through hoops to determine the correct information. The other half are hard-coded to use `python`, `spec['python'].prefix.lib`, and `spec['python'].prefix.include`. Obviously, none of these packages would work for Python 3, and there's no reason to duplicate the effort. The Python package itself should contain all of the information necessary to use it properly. This is in line with the recent work by @alalazo and @davydden with respect to `spec['blas'].libs` and friends.
## Prefix
For most packages in Spack, we assume that the installation directory is `spec['python'].prefix`. This generally works for anything installed with Spack, but gets complicated when we include external packages. Python is a commonly used external package (it needs to be installed just to run Spack). If it was installed with Homebrew, `which python` would return `/usr/local/bin/python`, and most users would erroneously assume that `/usr/local` is the installation directory. If you peruse through #2173, you'll immediately see why this is not the case. Homebrew actually installs Python in `/usr/local/Cellar/python/2.7.12_2` and symlinks the executable to `/usr/local/bin/python`. `PYTHONHOME` (and presumably most things that need to know where Python is installed) needs to be set to the actual installation directory, not `/usr/local`.
Normally I would say, "sounds like user error, make sure to use the real installation directory in your `packages.yaml`". But I think we can make a special case for Python. That's what we decided in #2173 anyway. If we change our minds, I would be more than happy to simplify things.
To solve this problem, I created a `spec['python'].home` attribute that works the same way as `spec['python'].prefix` but queries Python to figure out where it was actually installed. @tgamblin Is there any way to overwrite `spec['python'].prefix`? I think it's currently immutable.
## Command
In general, Python 2 comes with both `python` and `python2` commands, while Python 3 only comes with a `python3` command. But this is up to the OS developers. For example, `/usr/bin/python` on Gentoo is actually Python 3. Worse yet, if someone is using an externally installed Python, all 3 commands may exist in the same directory! Here's what I'm thinking:
If the spec is for Python 3, try searching for the `python3` command.
If the spec is for Python 2, try searching for the `python2` command.
If neither are found, try searching for the `python` command.
## Libraries
Spack installs Python libraries in `spec['python'].prefix.lib`. Except on openSUSE 13, where it installs to `spec['python'].prefix.lib64` (see #2295 and #2253). On my CentOS 6 machine, the Python libraries are installed in `/usr/lib64`. Both need to work.
The libraries themselves change name depending on OS and Python version. For Python 2.7 on macOS, I'm seeing:
```
lib/libpython2.7.dylib
```
For Python 3.6 on CentOS 6, I'm seeing:
```
lib/libpython3.so
lib/libpython3.6m.so.1.0
lib/libpython3.6m.so -> lib/libpython3.6m.so.1.0
```
Notice the `m` after the version number. Yeah, that's a thing.
## Headers
In Python 2.7, I'm seeing:
```
include/python2.7/pyconfig.h
```
In Python 3.6, I'm seeing:
```
include/python3.6m/pyconfig.h
```
It looks like all Python 3 installations have this `m`. Tested with Python 3.2 and 3.6 on macOS and CentOS 6
Spack has really nice support for libraries (`find_libraries` and `LibraryList`), but nothing for headers. Fixed.
2017-04-30 08:24:13 +08:00
|
|
|
class Python(AutotoolsPackage):
|
2014-10-31 06:02:06 +08:00
|
|
|
"""The Python programming language."""
|
2016-06-18 02:33:09 +08:00
|
|
|
|
2014-10-31 06:02:06 +08:00
|
|
|
homepage = "http://www.python.org"
|
2016-12-08 20:35:11 +08:00
|
|
|
url = "http://www.python.org/ftp/python/2.7.8/Python-2.7.8.tgz"
|
2016-12-26 10:53:16 +08:00
|
|
|
list_url = "https://www.python.org/downloads/"
|
2017-04-02 05:03:54 +08:00
|
|
|
list_depth = 1
|
2014-10-31 06:02:06 +08:00
|
|
|
|
2017-09-19 11:05:26 +08:00
|
|
|
version('3.6.2', 'e1a36bfffdd1d3a780b1825daf16e56c')
|
2017-04-28 22:55:02 +08:00
|
|
|
version('3.6.1', '2d0fc9f3a5940707590e07f03ecb08b9')
|
2017-01-07 00:50:06 +08:00
|
|
|
version('3.6.0', '3f7062ccf8be76491884d0e47ac8b251')
|
2016-07-07 20:09:08 +08:00
|
|
|
version('3.5.2', '3fe8434643a78630c61c6464fe2e7e72')
|
2016-01-09 06:16:30 +08:00
|
|
|
version('3.5.1', 'be78e48cdfc1a7ad90efff146dce6cfe')
|
|
|
|
version('3.5.0', 'a56c0c0b45d75a0ec9c6dee933c41c36')
|
2016-07-07 20:09:08 +08:00
|
|
|
version('3.4.3', '4281ff86778db65892c05151d5de738d')
|
|
|
|
version('3.3.6', 'cdb3cd08f96f074b3f3994ccb51063e9')
|
|
|
|
version('3.2.6', '23815d82ae706e9b781ca65865353d39')
|
|
|
|
version('3.1.5', '02196d3fc7bc76bdda68aa36b0dd16ab')
|
2017-09-19 11:05:26 +08:00
|
|
|
version('2.7.14', 'cee2e4b33ad3750da77b2e85f2f8b724', preferred=True)
|
|
|
|
version('2.7.13', '17add4bf0ad0ec2f08e0cae6d205c700')
|
2016-12-26 10:53:16 +08:00
|
|
|
version('2.7.12', '88d61f82e3616a4be952828b3694109d')
|
2016-07-07 20:09:08 +08:00
|
|
|
version('2.7.11', '6b6076ec9e93f05dd63e47eb9c15728b')
|
2016-01-09 06:16:30 +08:00
|
|
|
version('2.7.10', 'd7547558fd673bd9d38e2108c6b42521')
|
|
|
|
version('2.7.9', '5eebcaa0030dc4061156d3429657fb83')
|
|
|
|
version('2.7.8', 'd4bca0159acb0b44a781292b5231936f')
|
2014-10-31 06:02:06 +08:00
|
|
|
|
2016-06-18 02:33:09 +08:00
|
|
|
extendable = True
|
|
|
|
|
Python command, libraries, and headers (#3367)
## Motivation
Python installations are both important and unfortunately inconsistent. Depending on the Python version, OS, and the strength of the Earth's magnetic field when it was installed, the name of the Python executable, directory containing its libraries, library names, and the directory containing its headers can vary drastically.
I originally got into this mess with #3274, where I discovered that Boost could not be built with Python 3 because the executable is called `python3` and we were telling it to use `python`. I got deeper into this mess when I started hacking on #3140, where I discovered just how difficult it is to find the location and name of the Python libraries and headers.
Currently, half of the packages that depend on Python and need to know this information jump through hoops to determine the correct information. The other half are hard-coded to use `python`, `spec['python'].prefix.lib`, and `spec['python'].prefix.include`. Obviously, none of these packages would work for Python 3, and there's no reason to duplicate the effort. The Python package itself should contain all of the information necessary to use it properly. This is in line with the recent work by @alalazo and @davydden with respect to `spec['blas'].libs` and friends.
## Prefix
For most packages in Spack, we assume that the installation directory is `spec['python'].prefix`. This generally works for anything installed with Spack, but gets complicated when we include external packages. Python is a commonly used external package (it needs to be installed just to run Spack). If it was installed with Homebrew, `which python` would return `/usr/local/bin/python`, and most users would erroneously assume that `/usr/local` is the installation directory. If you peruse through #2173, you'll immediately see why this is not the case. Homebrew actually installs Python in `/usr/local/Cellar/python/2.7.12_2` and symlinks the executable to `/usr/local/bin/python`. `PYTHONHOME` (and presumably most things that need to know where Python is installed) needs to be set to the actual installation directory, not `/usr/local`.
Normally I would say, "sounds like user error, make sure to use the real installation directory in your `packages.yaml`". But I think we can make a special case for Python. That's what we decided in #2173 anyway. If we change our minds, I would be more than happy to simplify things.
To solve this problem, I created a `spec['python'].home` attribute that works the same way as `spec['python'].prefix` but queries Python to figure out where it was actually installed. @tgamblin Is there any way to overwrite `spec['python'].prefix`? I think it's currently immutable.
## Command
In general, Python 2 comes with both `python` and `python2` commands, while Python 3 only comes with a `python3` command. But this is up to the OS developers. For example, `/usr/bin/python` on Gentoo is actually Python 3. Worse yet, if someone is using an externally installed Python, all 3 commands may exist in the same directory! Here's what I'm thinking:
If the spec is for Python 3, try searching for the `python3` command.
If the spec is for Python 2, try searching for the `python2` command.
If neither are found, try searching for the `python` command.
## Libraries
Spack installs Python libraries in `spec['python'].prefix.lib`. Except on openSUSE 13, where it installs to `spec['python'].prefix.lib64` (see #2295 and #2253). On my CentOS 6 machine, the Python libraries are installed in `/usr/lib64`. Both need to work.
The libraries themselves change name depending on OS and Python version. For Python 2.7 on macOS, I'm seeing:
```
lib/libpython2.7.dylib
```
For Python 3.6 on CentOS 6, I'm seeing:
```
lib/libpython3.so
lib/libpython3.6m.so.1.0
lib/libpython3.6m.so -> lib/libpython3.6m.so.1.0
```
Notice the `m` after the version number. Yeah, that's a thing.
## Headers
In Python 2.7, I'm seeing:
```
include/python2.7/pyconfig.h
```
In Python 3.6, I'm seeing:
```
include/python3.6m/pyconfig.h
```
It looks like all Python 3 installations have this `m`. Tested with Python 3.2 and 3.6 on macOS and CentOS 6
Spack has really nice support for libraries (`find_libraries` and `LibraryList`), but nothing for headers. Fixed.
2017-04-30 08:24:13 +08:00
|
|
|
# --enable-shared is known to cause problems for some users on macOS
|
|
|
|
# See http://bugs.python.org/issue29846
|
|
|
|
variant('shared', default=sys.platform != 'darwin',
|
|
|
|
description='Enable shared libraries')
|
2016-12-08 20:35:11 +08:00
|
|
|
variant('tk', default=False, description='Provide support for Tkinter')
|
2016-08-10 16:50:00 +08:00
|
|
|
variant('ucs4', default=False,
|
|
|
|
description='Enable UCS4 (wide) unicode strings')
|
2016-07-08 20:47:25 +08:00
|
|
|
# From https://docs.python.org/2/c-api/unicode.html: Python's default
|
|
|
|
# builds use a 16-bit type for Py_UNICODE and store Unicode values
|
|
|
|
# internally as UCS2. It is also possible to build a UCS4 version of Python
|
|
|
|
# (most recent Linux distributions come with UCS4 builds of Python). These
|
|
|
|
# builds then use a 32-bit type for Py_UNICODE and store Unicode data
|
|
|
|
# internally as UCS4. Note that UCS2 and UCS4 Python builds are not binary
|
|
|
|
# compatible.
|
2017-09-22 09:14:31 +08:00
|
|
|
variant('pic', default=True,
|
|
|
|
description='Produce position-independent code (for shared libs)')
|
2016-07-07 01:29:54 +08:00
|
|
|
|
2014-10-31 06:02:06 +08:00
|
|
|
depends_on("openssl")
|
2014-11-03 16:15:05 +08:00
|
|
|
depends_on("bzip2")
|
|
|
|
depends_on("readline")
|
|
|
|
depends_on("ncurses")
|
2014-10-31 06:02:06 +08:00
|
|
|
depends_on("sqlite")
|
2015-12-02 22:20:11 +08:00
|
|
|
depends_on("zlib")
|
2016-12-08 20:35:11 +08:00
|
|
|
depends_on("tk", when="+tk")
|
2016-07-13 00:38:13 +08:00
|
|
|
depends_on("tcl", when="+tk")
|
2014-10-31 06:02:06 +08:00
|
|
|
|
Python command, libraries, and headers (#3367)
## Motivation
Python installations are both important and unfortunately inconsistent. Depending on the Python version, OS, and the strength of the Earth's magnetic field when it was installed, the name of the Python executable, directory containing its libraries, library names, and the directory containing its headers can vary drastically.
I originally got into this mess with #3274, where I discovered that Boost could not be built with Python 3 because the executable is called `python3` and we were telling it to use `python`. I got deeper into this mess when I started hacking on #3140, where I discovered just how difficult it is to find the location and name of the Python libraries and headers.
Currently, half of the packages that depend on Python and need to know this information jump through hoops to determine the correct information. The other half are hard-coded to use `python`, `spec['python'].prefix.lib`, and `spec['python'].prefix.include`. Obviously, none of these packages would work for Python 3, and there's no reason to duplicate the effort. The Python package itself should contain all of the information necessary to use it properly. This is in line with the recent work by @alalazo and @davydden with respect to `spec['blas'].libs` and friends.
## Prefix
For most packages in Spack, we assume that the installation directory is `spec['python'].prefix`. This generally works for anything installed with Spack, but gets complicated when we include external packages. Python is a commonly used external package (it needs to be installed just to run Spack). If it was installed with Homebrew, `which python` would return `/usr/local/bin/python`, and most users would erroneously assume that `/usr/local` is the installation directory. If you peruse through #2173, you'll immediately see why this is not the case. Homebrew actually installs Python in `/usr/local/Cellar/python/2.7.12_2` and symlinks the executable to `/usr/local/bin/python`. `PYTHONHOME` (and presumably most things that need to know where Python is installed) needs to be set to the actual installation directory, not `/usr/local`.
Normally I would say, "sounds like user error, make sure to use the real installation directory in your `packages.yaml`". But I think we can make a special case for Python. That's what we decided in #2173 anyway. If we change our minds, I would be more than happy to simplify things.
To solve this problem, I created a `spec['python'].home` attribute that works the same way as `spec['python'].prefix` but queries Python to figure out where it was actually installed. @tgamblin Is there any way to overwrite `spec['python'].prefix`? I think it's currently immutable.
## Command
In general, Python 2 comes with both `python` and `python2` commands, while Python 3 only comes with a `python3` command. But this is up to the OS developers. For example, `/usr/bin/python` on Gentoo is actually Python 3. Worse yet, if someone is using an externally installed Python, all 3 commands may exist in the same directory! Here's what I'm thinking:
If the spec is for Python 3, try searching for the `python3` command.
If the spec is for Python 2, try searching for the `python2` command.
If neither are found, try searching for the `python` command.
## Libraries
Spack installs Python libraries in `spec['python'].prefix.lib`. Except on openSUSE 13, where it installs to `spec['python'].prefix.lib64` (see #2295 and #2253). On my CentOS 6 machine, the Python libraries are installed in `/usr/lib64`. Both need to work.
The libraries themselves change name depending on OS and Python version. For Python 2.7 on macOS, I'm seeing:
```
lib/libpython2.7.dylib
```
For Python 3.6 on CentOS 6, I'm seeing:
```
lib/libpython3.so
lib/libpython3.6m.so.1.0
lib/libpython3.6m.so -> lib/libpython3.6m.so.1.0
```
Notice the `m` after the version number. Yeah, that's a thing.
## Headers
In Python 2.7, I'm seeing:
```
include/python2.7/pyconfig.h
```
In Python 3.6, I'm seeing:
```
include/python3.6m/pyconfig.h
```
It looks like all Python 3 installations have this `m`. Tested with Python 3.2 and 3.6 on macOS and CentOS 6
Spack has really nice support for libraries (`find_libraries` and `LibraryList`), but nothing for headers. Fixed.
2017-04-30 08:24:13 +08:00
|
|
|
# Patch does not work for Python 3.1
|
|
|
|
patch('ncurses.patch', when='@:2.8,3.2:')
|
2016-09-21 19:02:28 +08:00
|
|
|
|
2017-05-29 00:17:16 +08:00
|
|
|
# Ensure that distutils chooses correct compiler option for RPATH on cray:
|
|
|
|
patch('cray-rpath-2.3.patch', when="@2.3:3.0.1 platform=cray")
|
|
|
|
patch('cray-rpath-3.1.patch', when="@3.1:3.99 platform=cray")
|
|
|
|
|
2016-12-09 17:18:10 +08:00
|
|
|
_DISTUTIL_VARS_TO_SAVE = ['LDSHARED']
|
|
|
|
_DISTUTIL_CACHE_FILENAME = 'sysconfig.json'
|
|
|
|
_distutil_vars = None
|
|
|
|
|
Python command, libraries, and headers (#3367)
## Motivation
Python installations are both important and unfortunately inconsistent. Depending on the Python version, OS, and the strength of the Earth's magnetic field when it was installed, the name of the Python executable, directory containing its libraries, library names, and the directory containing its headers can vary drastically.
I originally got into this mess with #3274, where I discovered that Boost could not be built with Python 3 because the executable is called `python3` and we were telling it to use `python`. I got deeper into this mess when I started hacking on #3140, where I discovered just how difficult it is to find the location and name of the Python libraries and headers.
Currently, half of the packages that depend on Python and need to know this information jump through hoops to determine the correct information. The other half are hard-coded to use `python`, `spec['python'].prefix.lib`, and `spec['python'].prefix.include`. Obviously, none of these packages would work for Python 3, and there's no reason to duplicate the effort. The Python package itself should contain all of the information necessary to use it properly. This is in line with the recent work by @alalazo and @davydden with respect to `spec['blas'].libs` and friends.
## Prefix
For most packages in Spack, we assume that the installation directory is `spec['python'].prefix`. This generally works for anything installed with Spack, but gets complicated when we include external packages. Python is a commonly used external package (it needs to be installed just to run Spack). If it was installed with Homebrew, `which python` would return `/usr/local/bin/python`, and most users would erroneously assume that `/usr/local` is the installation directory. If you peruse through #2173, you'll immediately see why this is not the case. Homebrew actually installs Python in `/usr/local/Cellar/python/2.7.12_2` and symlinks the executable to `/usr/local/bin/python`. `PYTHONHOME` (and presumably most things that need to know where Python is installed) needs to be set to the actual installation directory, not `/usr/local`.
Normally I would say, "sounds like user error, make sure to use the real installation directory in your `packages.yaml`". But I think we can make a special case for Python. That's what we decided in #2173 anyway. If we change our minds, I would be more than happy to simplify things.
To solve this problem, I created a `spec['python'].home` attribute that works the same way as `spec['python'].prefix` but queries Python to figure out where it was actually installed. @tgamblin Is there any way to overwrite `spec['python'].prefix`? I think it's currently immutable.
## Command
In general, Python 2 comes with both `python` and `python2` commands, while Python 3 only comes with a `python3` command. But this is up to the OS developers. For example, `/usr/bin/python` on Gentoo is actually Python 3. Worse yet, if someone is using an externally installed Python, all 3 commands may exist in the same directory! Here's what I'm thinking:
If the spec is for Python 3, try searching for the `python3` command.
If the spec is for Python 2, try searching for the `python2` command.
If neither are found, try searching for the `python` command.
## Libraries
Spack installs Python libraries in `spec['python'].prefix.lib`. Except on openSUSE 13, where it installs to `spec['python'].prefix.lib64` (see #2295 and #2253). On my CentOS 6 machine, the Python libraries are installed in `/usr/lib64`. Both need to work.
The libraries themselves change name depending on OS and Python version. For Python 2.7 on macOS, I'm seeing:
```
lib/libpython2.7.dylib
```
For Python 3.6 on CentOS 6, I'm seeing:
```
lib/libpython3.so
lib/libpython3.6m.so.1.0
lib/libpython3.6m.so -> lib/libpython3.6m.so.1.0
```
Notice the `m` after the version number. Yeah, that's a thing.
## Headers
In Python 2.7, I'm seeing:
```
include/python2.7/pyconfig.h
```
In Python 3.6, I'm seeing:
```
include/python3.6m/pyconfig.h
```
It looks like all Python 3 installations have this `m`. Tested with Python 3.2 and 3.6 on macOS and CentOS 6
Spack has really nice support for libraries (`find_libraries` and `LibraryList`), but nothing for headers. Fixed.
2017-04-30 08:24:13 +08:00
|
|
|
@when('@2.7:2.8,3.4:')
|
2016-07-23 02:08:08 +08:00
|
|
|
def patch(self):
|
|
|
|
# NOTE: Python's default installation procedure makes it possible for a
|
|
|
|
# user's local configurations to change the Spack installation. In
|
|
|
|
# order to prevent this behavior for a full installation, we must
|
|
|
|
# modify the installation script so that it ignores user files.
|
|
|
|
ff = FileFilter('Makefile.pre.in')
|
|
|
|
ff.filter(
|
|
|
|
r'^(.*)setup\.py(.*)((build)|(install))(.*)$',
|
|
|
|
r'\1setup.py\2 --no-user-cfg \3\6'
|
|
|
|
)
|
|
|
|
|
Python command, libraries, and headers (#3367)
## Motivation
Python installations are both important and unfortunately inconsistent. Depending on the Python version, OS, and the strength of the Earth's magnetic field when it was installed, the name of the Python executable, directory containing its libraries, library names, and the directory containing its headers can vary drastically.
I originally got into this mess with #3274, where I discovered that Boost could not be built with Python 3 because the executable is called `python3` and we were telling it to use `python`. I got deeper into this mess when I started hacking on #3140, where I discovered just how difficult it is to find the location and name of the Python libraries and headers.
Currently, half of the packages that depend on Python and need to know this information jump through hoops to determine the correct information. The other half are hard-coded to use `python`, `spec['python'].prefix.lib`, and `spec['python'].prefix.include`. Obviously, none of these packages would work for Python 3, and there's no reason to duplicate the effort. The Python package itself should contain all of the information necessary to use it properly. This is in line with the recent work by @alalazo and @davydden with respect to `spec['blas'].libs` and friends.
## Prefix
For most packages in Spack, we assume that the installation directory is `spec['python'].prefix`. This generally works for anything installed with Spack, but gets complicated when we include external packages. Python is a commonly used external package (it needs to be installed just to run Spack). If it was installed with Homebrew, `which python` would return `/usr/local/bin/python`, and most users would erroneously assume that `/usr/local` is the installation directory. If you peruse through #2173, you'll immediately see why this is not the case. Homebrew actually installs Python in `/usr/local/Cellar/python/2.7.12_2` and symlinks the executable to `/usr/local/bin/python`. `PYTHONHOME` (and presumably most things that need to know where Python is installed) needs to be set to the actual installation directory, not `/usr/local`.
Normally I would say, "sounds like user error, make sure to use the real installation directory in your `packages.yaml`". But I think we can make a special case for Python. That's what we decided in #2173 anyway. If we change our minds, I would be more than happy to simplify things.
To solve this problem, I created a `spec['python'].home` attribute that works the same way as `spec['python'].prefix` but queries Python to figure out where it was actually installed. @tgamblin Is there any way to overwrite `spec['python'].prefix`? I think it's currently immutable.
## Command
In general, Python 2 comes with both `python` and `python2` commands, while Python 3 only comes with a `python3` command. But this is up to the OS developers. For example, `/usr/bin/python` on Gentoo is actually Python 3. Worse yet, if someone is using an externally installed Python, all 3 commands may exist in the same directory! Here's what I'm thinking:
If the spec is for Python 3, try searching for the `python3` command.
If the spec is for Python 2, try searching for the `python2` command.
If neither are found, try searching for the `python` command.
## Libraries
Spack installs Python libraries in `spec['python'].prefix.lib`. Except on openSUSE 13, where it installs to `spec['python'].prefix.lib64` (see #2295 and #2253). On my CentOS 6 machine, the Python libraries are installed in `/usr/lib64`. Both need to work.
The libraries themselves change name depending on OS and Python version. For Python 2.7 on macOS, I'm seeing:
```
lib/libpython2.7.dylib
```
For Python 3.6 on CentOS 6, I'm seeing:
```
lib/libpython3.so
lib/libpython3.6m.so.1.0
lib/libpython3.6m.so -> lib/libpython3.6m.so.1.0
```
Notice the `m` after the version number. Yeah, that's a thing.
## Headers
In Python 2.7, I'm seeing:
```
include/python2.7/pyconfig.h
```
In Python 3.6, I'm seeing:
```
include/python3.6m/pyconfig.h
```
It looks like all Python 3 installations have this `m`. Tested with Python 3.2 and 3.6 on macOS and CentOS 6
Spack has really nice support for libraries (`find_libraries` and `LibraryList`), but nothing for headers. Fixed.
2017-04-30 08:24:13 +08:00
|
|
|
def setup_environment(self, spack_env, run_env):
|
|
|
|
spec = self.spec
|
|
|
|
prefix = self.prefix
|
|
|
|
|
2016-07-23 02:08:08 +08:00
|
|
|
# TODO: The '--no-user-cfg' option for Python installation is only in
|
|
|
|
# Python v2.7 and v3.4+ (see https://bugs.python.org/issue1180) and
|
|
|
|
# adding support for ignoring user configuration will require
|
|
|
|
# significant changes to this package for other Python versions.
|
|
|
|
if not spec.satisfies('@2.7,3.4:'):
|
|
|
|
tty.warn(('Python v{0} may not install properly if Python '
|
|
|
|
'user configurations are present.').format(self.version))
|
|
|
|
|
2014-11-03 16:15:05 +08:00
|
|
|
# Need this to allow python build to find the Python installation.
|
Python command, libraries, and headers (#3367)
## Motivation
Python installations are both important and unfortunately inconsistent. Depending on the Python version, OS, and the strength of the Earth's magnetic field when it was installed, the name of the Python executable, directory containing its libraries, library names, and the directory containing its headers can vary drastically.
I originally got into this mess with #3274, where I discovered that Boost could not be built with Python 3 because the executable is called `python3` and we were telling it to use `python`. I got deeper into this mess when I started hacking on #3140, where I discovered just how difficult it is to find the location and name of the Python libraries and headers.
Currently, half of the packages that depend on Python and need to know this information jump through hoops to determine the correct information. The other half are hard-coded to use `python`, `spec['python'].prefix.lib`, and `spec['python'].prefix.include`. Obviously, none of these packages would work for Python 3, and there's no reason to duplicate the effort. The Python package itself should contain all of the information necessary to use it properly. This is in line with the recent work by @alalazo and @davydden with respect to `spec['blas'].libs` and friends.
## Prefix
For most packages in Spack, we assume that the installation directory is `spec['python'].prefix`. This generally works for anything installed with Spack, but gets complicated when we include external packages. Python is a commonly used external package (it needs to be installed just to run Spack). If it was installed with Homebrew, `which python` would return `/usr/local/bin/python`, and most users would erroneously assume that `/usr/local` is the installation directory. If you peruse through #2173, you'll immediately see why this is not the case. Homebrew actually installs Python in `/usr/local/Cellar/python/2.7.12_2` and symlinks the executable to `/usr/local/bin/python`. `PYTHONHOME` (and presumably most things that need to know where Python is installed) needs to be set to the actual installation directory, not `/usr/local`.
Normally I would say, "sounds like user error, make sure to use the real installation directory in your `packages.yaml`". But I think we can make a special case for Python. That's what we decided in #2173 anyway. If we change our minds, I would be more than happy to simplify things.
To solve this problem, I created a `spec['python'].home` attribute that works the same way as `spec['python'].prefix` but queries Python to figure out where it was actually installed. @tgamblin Is there any way to overwrite `spec['python'].prefix`? I think it's currently immutable.
## Command
In general, Python 2 comes with both `python` and `python2` commands, while Python 3 only comes with a `python3` command. But this is up to the OS developers. For example, `/usr/bin/python` on Gentoo is actually Python 3. Worse yet, if someone is using an externally installed Python, all 3 commands may exist in the same directory! Here's what I'm thinking:
If the spec is for Python 3, try searching for the `python3` command.
If the spec is for Python 2, try searching for the `python2` command.
If neither are found, try searching for the `python` command.
## Libraries
Spack installs Python libraries in `spec['python'].prefix.lib`. Except on openSUSE 13, where it installs to `spec['python'].prefix.lib64` (see #2295 and #2253). On my CentOS 6 machine, the Python libraries are installed in `/usr/lib64`. Both need to work.
The libraries themselves change name depending on OS and Python version. For Python 2.7 on macOS, I'm seeing:
```
lib/libpython2.7.dylib
```
For Python 3.6 on CentOS 6, I'm seeing:
```
lib/libpython3.so
lib/libpython3.6m.so.1.0
lib/libpython3.6m.so -> lib/libpython3.6m.so.1.0
```
Notice the `m` after the version number. Yeah, that's a thing.
## Headers
In Python 2.7, I'm seeing:
```
include/python2.7/pyconfig.h
```
In Python 3.6, I'm seeing:
```
include/python3.6m/pyconfig.h
```
It looks like all Python 3 installations have this `m`. Tested with Python 3.2 and 3.6 on macOS and CentOS 6
Spack has really nice support for libraries (`find_libraries` and `LibraryList`), but nothing for headers. Fixed.
2017-04-30 08:24:13 +08:00
|
|
|
spack_env.set('PYTHONHOME', prefix)
|
|
|
|
spack_env.set('PYTHONPATH', prefix)
|
|
|
|
spack_env.set('MACOSX_DEPLOYMENT_TARGET', platform.mac_ver()[0])
|
|
|
|
|
|
|
|
def configure_args(self):
|
|
|
|
spec = self.spec
|
2014-11-03 16:15:05 +08:00
|
|
|
|
Python command, libraries, and headers (#3367)
## Motivation
Python installations are both important and unfortunately inconsistent. Depending on the Python version, OS, and the strength of the Earth's magnetic field when it was installed, the name of the Python executable, directory containing its libraries, library names, and the directory containing its headers can vary drastically.
I originally got into this mess with #3274, where I discovered that Boost could not be built with Python 3 because the executable is called `python3` and we were telling it to use `python`. I got deeper into this mess when I started hacking on #3140, where I discovered just how difficult it is to find the location and name of the Python libraries and headers.
Currently, half of the packages that depend on Python and need to know this information jump through hoops to determine the correct information. The other half are hard-coded to use `python`, `spec['python'].prefix.lib`, and `spec['python'].prefix.include`. Obviously, none of these packages would work for Python 3, and there's no reason to duplicate the effort. The Python package itself should contain all of the information necessary to use it properly. This is in line with the recent work by @alalazo and @davydden with respect to `spec['blas'].libs` and friends.
## Prefix
For most packages in Spack, we assume that the installation directory is `spec['python'].prefix`. This generally works for anything installed with Spack, but gets complicated when we include external packages. Python is a commonly used external package (it needs to be installed just to run Spack). If it was installed with Homebrew, `which python` would return `/usr/local/bin/python`, and most users would erroneously assume that `/usr/local` is the installation directory. If you peruse through #2173, you'll immediately see why this is not the case. Homebrew actually installs Python in `/usr/local/Cellar/python/2.7.12_2` and symlinks the executable to `/usr/local/bin/python`. `PYTHONHOME` (and presumably most things that need to know where Python is installed) needs to be set to the actual installation directory, not `/usr/local`.
Normally I would say, "sounds like user error, make sure to use the real installation directory in your `packages.yaml`". But I think we can make a special case for Python. That's what we decided in #2173 anyway. If we change our minds, I would be more than happy to simplify things.
To solve this problem, I created a `spec['python'].home` attribute that works the same way as `spec['python'].prefix` but queries Python to figure out where it was actually installed. @tgamblin Is there any way to overwrite `spec['python'].prefix`? I think it's currently immutable.
## Command
In general, Python 2 comes with both `python` and `python2` commands, while Python 3 only comes with a `python3` command. But this is up to the OS developers. For example, `/usr/bin/python` on Gentoo is actually Python 3. Worse yet, if someone is using an externally installed Python, all 3 commands may exist in the same directory! Here's what I'm thinking:
If the spec is for Python 3, try searching for the `python3` command.
If the spec is for Python 2, try searching for the `python2` command.
If neither are found, try searching for the `python` command.
## Libraries
Spack installs Python libraries in `spec['python'].prefix.lib`. Except on openSUSE 13, where it installs to `spec['python'].prefix.lib64` (see #2295 and #2253). On my CentOS 6 machine, the Python libraries are installed in `/usr/lib64`. Both need to work.
The libraries themselves change name depending on OS and Python version. For Python 2.7 on macOS, I'm seeing:
```
lib/libpython2.7.dylib
```
For Python 3.6 on CentOS 6, I'm seeing:
```
lib/libpython3.so
lib/libpython3.6m.so.1.0
lib/libpython3.6m.so -> lib/libpython3.6m.so.1.0
```
Notice the `m` after the version number. Yeah, that's a thing.
## Headers
In Python 2.7, I'm seeing:
```
include/python2.7/pyconfig.h
```
In Python 3.6, I'm seeing:
```
include/python3.6m/pyconfig.h
```
It looks like all Python 3 installations have this `m`. Tested with Python 3.2 and 3.6 on macOS and CentOS 6
Spack has really nice support for libraries (`find_libraries` and `LibraryList`), but nothing for headers. Fixed.
2017-04-30 08:24:13 +08:00
|
|
|
# setup.py needs to be able to read the CPPFLAGS and LDFLAGS
|
|
|
|
# as it scans for the library and headers to build
|
2016-07-23 02:12:02 +08:00
|
|
|
dep_pfxs = [dspec.prefix for dspec in spec.dependencies('link')]
|
2016-06-18 02:33:09 +08:00
|
|
|
config_args = [
|
2016-07-23 02:12:02 +08:00
|
|
|
'--with-threads',
|
|
|
|
'CPPFLAGS=-I{0}'.format(' -I'.join(dp.include for dp in dep_pfxs)),
|
|
|
|
'LDFLAGS=-L{0}'.format(' -L'.join(dp.lib for dp in dep_pfxs)),
|
2016-06-18 02:33:09 +08:00
|
|
|
]
|
Python command, libraries, and headers (#3367)
## Motivation
Python installations are both important and unfortunately inconsistent. Depending on the Python version, OS, and the strength of the Earth's magnetic field when it was installed, the name of the Python executable, directory containing its libraries, library names, and the directory containing its headers can vary drastically.
I originally got into this mess with #3274, where I discovered that Boost could not be built with Python 3 because the executable is called `python3` and we were telling it to use `python`. I got deeper into this mess when I started hacking on #3140, where I discovered just how difficult it is to find the location and name of the Python libraries and headers.
Currently, half of the packages that depend on Python and need to know this information jump through hoops to determine the correct information. The other half are hard-coded to use `python`, `spec['python'].prefix.lib`, and `spec['python'].prefix.include`. Obviously, none of these packages would work for Python 3, and there's no reason to duplicate the effort. The Python package itself should contain all of the information necessary to use it properly. This is in line with the recent work by @alalazo and @davydden with respect to `spec['blas'].libs` and friends.
## Prefix
For most packages in Spack, we assume that the installation directory is `spec['python'].prefix`. This generally works for anything installed with Spack, but gets complicated when we include external packages. Python is a commonly used external package (it needs to be installed just to run Spack). If it was installed with Homebrew, `which python` would return `/usr/local/bin/python`, and most users would erroneously assume that `/usr/local` is the installation directory. If you peruse through #2173, you'll immediately see why this is not the case. Homebrew actually installs Python in `/usr/local/Cellar/python/2.7.12_2` and symlinks the executable to `/usr/local/bin/python`. `PYTHONHOME` (and presumably most things that need to know where Python is installed) needs to be set to the actual installation directory, not `/usr/local`.
Normally I would say, "sounds like user error, make sure to use the real installation directory in your `packages.yaml`". But I think we can make a special case for Python. That's what we decided in #2173 anyway. If we change our minds, I would be more than happy to simplify things.
To solve this problem, I created a `spec['python'].home` attribute that works the same way as `spec['python'].prefix` but queries Python to figure out where it was actually installed. @tgamblin Is there any way to overwrite `spec['python'].prefix`? I think it's currently immutable.
## Command
In general, Python 2 comes with both `python` and `python2` commands, while Python 3 only comes with a `python3` command. But this is up to the OS developers. For example, `/usr/bin/python` on Gentoo is actually Python 3. Worse yet, if someone is using an externally installed Python, all 3 commands may exist in the same directory! Here's what I'm thinking:
If the spec is for Python 3, try searching for the `python3` command.
If the spec is for Python 2, try searching for the `python2` command.
If neither are found, try searching for the `python` command.
## Libraries
Spack installs Python libraries in `spec['python'].prefix.lib`. Except on openSUSE 13, where it installs to `spec['python'].prefix.lib64` (see #2295 and #2253). On my CentOS 6 machine, the Python libraries are installed in `/usr/lib64`. Both need to work.
The libraries themselves change name depending on OS and Python version. For Python 2.7 on macOS, I'm seeing:
```
lib/libpython2.7.dylib
```
For Python 3.6 on CentOS 6, I'm seeing:
```
lib/libpython3.so
lib/libpython3.6m.so.1.0
lib/libpython3.6m.so -> lib/libpython3.6m.so.1.0
```
Notice the `m` after the version number. Yeah, that's a thing.
## Headers
In Python 2.7, I'm seeing:
```
include/python2.7/pyconfig.h
```
In Python 3.6, I'm seeing:
```
include/python3.6m/pyconfig.h
```
It looks like all Python 3 installations have this `m`. Tested with Python 3.2 and 3.6 on macOS and CentOS 6
Spack has really nice support for libraries (`find_libraries` and `LibraryList`), but nothing for headers. Fixed.
2017-04-30 08:24:13 +08:00
|
|
|
if spec.satisfies('%gcc platform=darwin'):
|
2016-09-01 01:13:08 +08:00
|
|
|
config_args.append('--disable-toolbox-glue')
|
2016-06-18 02:33:09 +08:00
|
|
|
|
Python command, libraries, and headers (#3367)
## Motivation
Python installations are both important and unfortunately inconsistent. Depending on the Python version, OS, and the strength of the Earth's magnetic field when it was installed, the name of the Python executable, directory containing its libraries, library names, and the directory containing its headers can vary drastically.
I originally got into this mess with #3274, where I discovered that Boost could not be built with Python 3 because the executable is called `python3` and we were telling it to use `python`. I got deeper into this mess when I started hacking on #3140, where I discovered just how difficult it is to find the location and name of the Python libraries and headers.
Currently, half of the packages that depend on Python and need to know this information jump through hoops to determine the correct information. The other half are hard-coded to use `python`, `spec['python'].prefix.lib`, and `spec['python'].prefix.include`. Obviously, none of these packages would work for Python 3, and there's no reason to duplicate the effort. The Python package itself should contain all of the information necessary to use it properly. This is in line with the recent work by @alalazo and @davydden with respect to `spec['blas'].libs` and friends.
## Prefix
For most packages in Spack, we assume that the installation directory is `spec['python'].prefix`. This generally works for anything installed with Spack, but gets complicated when we include external packages. Python is a commonly used external package (it needs to be installed just to run Spack). If it was installed with Homebrew, `which python` would return `/usr/local/bin/python`, and most users would erroneously assume that `/usr/local` is the installation directory. If you peruse through #2173, you'll immediately see why this is not the case. Homebrew actually installs Python in `/usr/local/Cellar/python/2.7.12_2` and symlinks the executable to `/usr/local/bin/python`. `PYTHONHOME` (and presumably most things that need to know where Python is installed) needs to be set to the actual installation directory, not `/usr/local`.
Normally I would say, "sounds like user error, make sure to use the real installation directory in your `packages.yaml`". But I think we can make a special case for Python. That's what we decided in #2173 anyway. If we change our minds, I would be more than happy to simplify things.
To solve this problem, I created a `spec['python'].home` attribute that works the same way as `spec['python'].prefix` but queries Python to figure out where it was actually installed. @tgamblin Is there any way to overwrite `spec['python'].prefix`? I think it's currently immutable.
## Command
In general, Python 2 comes with both `python` and `python2` commands, while Python 3 only comes with a `python3` command. But this is up to the OS developers. For example, `/usr/bin/python` on Gentoo is actually Python 3. Worse yet, if someone is using an externally installed Python, all 3 commands may exist in the same directory! Here's what I'm thinking:
If the spec is for Python 3, try searching for the `python3` command.
If the spec is for Python 2, try searching for the `python2` command.
If neither are found, try searching for the `python` command.
## Libraries
Spack installs Python libraries in `spec['python'].prefix.lib`. Except on openSUSE 13, where it installs to `spec['python'].prefix.lib64` (see #2295 and #2253). On my CentOS 6 machine, the Python libraries are installed in `/usr/lib64`. Both need to work.
The libraries themselves change name depending on OS and Python version. For Python 2.7 on macOS, I'm seeing:
```
lib/libpython2.7.dylib
```
For Python 3.6 on CentOS 6, I'm seeing:
```
lib/libpython3.so
lib/libpython3.6m.so.1.0
lib/libpython3.6m.so -> lib/libpython3.6m.so.1.0
```
Notice the `m` after the version number. Yeah, that's a thing.
## Headers
In Python 2.7, I'm seeing:
```
include/python2.7/pyconfig.h
```
In Python 3.6, I'm seeing:
```
include/python3.6m/pyconfig.h
```
It looks like all Python 3 installations have this `m`. Tested with Python 3.2 and 3.6 on macOS and CentOS 6
Spack has really nice support for libraries (`find_libraries` and `LibraryList`), but nothing for headers. Fixed.
2017-04-30 08:24:13 +08:00
|
|
|
if '+shared' in spec:
|
|
|
|
config_args.append('--enable-shared')
|
2017-09-22 09:14:31 +08:00
|
|
|
else:
|
|
|
|
config_args.append('--disable-shared')
|
Python command, libraries, and headers (#3367)
## Motivation
Python installations are both important and unfortunately inconsistent. Depending on the Python version, OS, and the strength of the Earth's magnetic field when it was installed, the name of the Python executable, directory containing its libraries, library names, and the directory containing its headers can vary drastically.
I originally got into this mess with #3274, where I discovered that Boost could not be built with Python 3 because the executable is called `python3` and we were telling it to use `python`. I got deeper into this mess when I started hacking on #3140, where I discovered just how difficult it is to find the location and name of the Python libraries and headers.
Currently, half of the packages that depend on Python and need to know this information jump through hoops to determine the correct information. The other half are hard-coded to use `python`, `spec['python'].prefix.lib`, and `spec['python'].prefix.include`. Obviously, none of these packages would work for Python 3, and there's no reason to duplicate the effort. The Python package itself should contain all of the information necessary to use it properly. This is in line with the recent work by @alalazo and @davydden with respect to `spec['blas'].libs` and friends.
## Prefix
For most packages in Spack, we assume that the installation directory is `spec['python'].prefix`. This generally works for anything installed with Spack, but gets complicated when we include external packages. Python is a commonly used external package (it needs to be installed just to run Spack). If it was installed with Homebrew, `which python` would return `/usr/local/bin/python`, and most users would erroneously assume that `/usr/local` is the installation directory. If you peruse through #2173, you'll immediately see why this is not the case. Homebrew actually installs Python in `/usr/local/Cellar/python/2.7.12_2` and symlinks the executable to `/usr/local/bin/python`. `PYTHONHOME` (and presumably most things that need to know where Python is installed) needs to be set to the actual installation directory, not `/usr/local`.
Normally I would say, "sounds like user error, make sure to use the real installation directory in your `packages.yaml`". But I think we can make a special case for Python. That's what we decided in #2173 anyway. If we change our minds, I would be more than happy to simplify things.
To solve this problem, I created a `spec['python'].home` attribute that works the same way as `spec['python'].prefix` but queries Python to figure out where it was actually installed. @tgamblin Is there any way to overwrite `spec['python'].prefix`? I think it's currently immutable.
## Command
In general, Python 2 comes with both `python` and `python2` commands, while Python 3 only comes with a `python3` command. But this is up to the OS developers. For example, `/usr/bin/python` on Gentoo is actually Python 3. Worse yet, if someone is using an externally installed Python, all 3 commands may exist in the same directory! Here's what I'm thinking:
If the spec is for Python 3, try searching for the `python3` command.
If the spec is for Python 2, try searching for the `python2` command.
If neither are found, try searching for the `python` command.
## Libraries
Spack installs Python libraries in `spec['python'].prefix.lib`. Except on openSUSE 13, where it installs to `spec['python'].prefix.lib64` (see #2295 and #2253). On my CentOS 6 machine, the Python libraries are installed in `/usr/lib64`. Both need to work.
The libraries themselves change name depending on OS and Python version. For Python 2.7 on macOS, I'm seeing:
```
lib/libpython2.7.dylib
```
For Python 3.6 on CentOS 6, I'm seeing:
```
lib/libpython3.so
lib/libpython3.6m.so.1.0
lib/libpython3.6m.so -> lib/libpython3.6m.so.1.0
```
Notice the `m` after the version number. Yeah, that's a thing.
## Headers
In Python 2.7, I'm seeing:
```
include/python2.7/pyconfig.h
```
In Python 3.6, I'm seeing:
```
include/python3.6m/pyconfig.h
```
It looks like all Python 3 installations have this `m`. Tested with Python 3.2 and 3.6 on macOS and CentOS 6
Spack has really nice support for libraries (`find_libraries` and `LibraryList`), but nothing for headers. Fixed.
2017-04-30 08:24:13 +08:00
|
|
|
|
2016-07-07 01:29:54 +08:00
|
|
|
if '+ucs4' in spec:
|
2016-07-07 20:18:40 +08:00
|
|
|
if spec.satisfies('@:2.7'):
|
2016-07-07 20:12:43 +08:00
|
|
|
config_args.append('--enable-unicode=ucs4')
|
|
|
|
elif spec.satisfies('@3.0:3.2'):
|
2016-07-07 21:00:37 +08:00
|
|
|
config_args.append('--with-wide-unicode')
|
2016-07-08 20:47:25 +08:00
|
|
|
elif spec.satisfies('@3.3:'):
|
|
|
|
# https://docs.python.org/3.3/whatsnew/3.3.html
|
2016-08-11 05:05:59 +08:00
|
|
|
raise ValueError(
|
|
|
|
'+ucs4 variant not compatible with Python 3.3 and beyond')
|
2016-07-07 01:29:54 +08:00
|
|
|
|
2015-12-22 22:50:18 +08:00
|
|
|
if spec.satisfies('@3:'):
|
2016-06-18 02:33:09 +08:00
|
|
|
config_args.append('--without-ensurepip')
|
|
|
|
|
2017-09-22 09:14:31 +08:00
|
|
|
if '+pic' in spec:
|
|
|
|
config_args.append('CFLAGS={0}'.format(self.compiler.pic_flag))
|
|
|
|
|
Python command, libraries, and headers (#3367)
## Motivation
Python installations are both important and unfortunately inconsistent. Depending on the Python version, OS, and the strength of the Earth's magnetic field when it was installed, the name of the Python executable, directory containing its libraries, library names, and the directory containing its headers can vary drastically.
I originally got into this mess with #3274, where I discovered that Boost could not be built with Python 3 because the executable is called `python3` and we were telling it to use `python`. I got deeper into this mess when I started hacking on #3140, where I discovered just how difficult it is to find the location and name of the Python libraries and headers.
Currently, half of the packages that depend on Python and need to know this information jump through hoops to determine the correct information. The other half are hard-coded to use `python`, `spec['python'].prefix.lib`, and `spec['python'].prefix.include`. Obviously, none of these packages would work for Python 3, and there's no reason to duplicate the effort. The Python package itself should contain all of the information necessary to use it properly. This is in line with the recent work by @alalazo and @davydden with respect to `spec['blas'].libs` and friends.
## Prefix
For most packages in Spack, we assume that the installation directory is `spec['python'].prefix`. This generally works for anything installed with Spack, but gets complicated when we include external packages. Python is a commonly used external package (it needs to be installed just to run Spack). If it was installed with Homebrew, `which python` would return `/usr/local/bin/python`, and most users would erroneously assume that `/usr/local` is the installation directory. If you peruse through #2173, you'll immediately see why this is not the case. Homebrew actually installs Python in `/usr/local/Cellar/python/2.7.12_2` and symlinks the executable to `/usr/local/bin/python`. `PYTHONHOME` (and presumably most things that need to know where Python is installed) needs to be set to the actual installation directory, not `/usr/local`.
Normally I would say, "sounds like user error, make sure to use the real installation directory in your `packages.yaml`". But I think we can make a special case for Python. That's what we decided in #2173 anyway. If we change our minds, I would be more than happy to simplify things.
To solve this problem, I created a `spec['python'].home` attribute that works the same way as `spec['python'].prefix` but queries Python to figure out where it was actually installed. @tgamblin Is there any way to overwrite `spec['python'].prefix`? I think it's currently immutable.
## Command
In general, Python 2 comes with both `python` and `python2` commands, while Python 3 only comes with a `python3` command. But this is up to the OS developers. For example, `/usr/bin/python` on Gentoo is actually Python 3. Worse yet, if someone is using an externally installed Python, all 3 commands may exist in the same directory! Here's what I'm thinking:
If the spec is for Python 3, try searching for the `python3` command.
If the spec is for Python 2, try searching for the `python2` command.
If neither are found, try searching for the `python` command.
## Libraries
Spack installs Python libraries in `spec['python'].prefix.lib`. Except on openSUSE 13, where it installs to `spec['python'].prefix.lib64` (see #2295 and #2253). On my CentOS 6 machine, the Python libraries are installed in `/usr/lib64`. Both need to work.
The libraries themselves change name depending on OS and Python version. For Python 2.7 on macOS, I'm seeing:
```
lib/libpython2.7.dylib
```
For Python 3.6 on CentOS 6, I'm seeing:
```
lib/libpython3.so
lib/libpython3.6m.so.1.0
lib/libpython3.6m.so -> lib/libpython3.6m.so.1.0
```
Notice the `m` after the version number. Yeah, that's a thing.
## Headers
In Python 2.7, I'm seeing:
```
include/python2.7/pyconfig.h
```
In Python 3.6, I'm seeing:
```
include/python3.6m/pyconfig.h
```
It looks like all Python 3 installations have this `m`. Tested with Python 3.2 and 3.6 on macOS and CentOS 6
Spack has really nice support for libraries (`find_libraries` and `LibraryList`), but nothing for headers. Fixed.
2017-04-30 08:24:13 +08:00
|
|
|
return config_args
|
|
|
|
|
|
|
|
@run_after('install')
|
|
|
|
def post_install(self):
|
|
|
|
spec = self.spec
|
|
|
|
prefix = self.prefix
|
2015-01-11 11:37:01 +08:00
|
|
|
|
2017-01-24 01:34:50 +08:00
|
|
|
self.sysconfigfilename = '_sysconfigdata.py'
|
|
|
|
if spec.satisfies('@3.6:'):
|
|
|
|
# Python 3.6.0 renamed the sys config file
|
|
|
|
sc = 'import sysconfig; print(sysconfig._get_sysconfigdata_name())'
|
Python command, libraries, and headers (#3367)
## Motivation
Python installations are both important and unfortunately inconsistent. Depending on the Python version, OS, and the strength of the Earth's magnetic field when it was installed, the name of the Python executable, directory containing its libraries, library names, and the directory containing its headers can vary drastically.
I originally got into this mess with #3274, where I discovered that Boost could not be built with Python 3 because the executable is called `python3` and we were telling it to use `python`. I got deeper into this mess when I started hacking on #3140, where I discovered just how difficult it is to find the location and name of the Python libraries and headers.
Currently, half of the packages that depend on Python and need to know this information jump through hoops to determine the correct information. The other half are hard-coded to use `python`, `spec['python'].prefix.lib`, and `spec['python'].prefix.include`. Obviously, none of these packages would work for Python 3, and there's no reason to duplicate the effort. The Python package itself should contain all of the information necessary to use it properly. This is in line with the recent work by @alalazo and @davydden with respect to `spec['blas'].libs` and friends.
## Prefix
For most packages in Spack, we assume that the installation directory is `spec['python'].prefix`. This generally works for anything installed with Spack, but gets complicated when we include external packages. Python is a commonly used external package (it needs to be installed just to run Spack). If it was installed with Homebrew, `which python` would return `/usr/local/bin/python`, and most users would erroneously assume that `/usr/local` is the installation directory. If you peruse through #2173, you'll immediately see why this is not the case. Homebrew actually installs Python in `/usr/local/Cellar/python/2.7.12_2` and symlinks the executable to `/usr/local/bin/python`. `PYTHONHOME` (and presumably most things that need to know where Python is installed) needs to be set to the actual installation directory, not `/usr/local`.
Normally I would say, "sounds like user error, make sure to use the real installation directory in your `packages.yaml`". But I think we can make a special case for Python. That's what we decided in #2173 anyway. If we change our minds, I would be more than happy to simplify things.
To solve this problem, I created a `spec['python'].home` attribute that works the same way as `spec['python'].prefix` but queries Python to figure out where it was actually installed. @tgamblin Is there any way to overwrite `spec['python'].prefix`? I think it's currently immutable.
## Command
In general, Python 2 comes with both `python` and `python2` commands, while Python 3 only comes with a `python3` command. But this is up to the OS developers. For example, `/usr/bin/python` on Gentoo is actually Python 3. Worse yet, if someone is using an externally installed Python, all 3 commands may exist in the same directory! Here's what I'm thinking:
If the spec is for Python 3, try searching for the `python3` command.
If the spec is for Python 2, try searching for the `python2` command.
If neither are found, try searching for the `python` command.
## Libraries
Spack installs Python libraries in `spec['python'].prefix.lib`. Except on openSUSE 13, where it installs to `spec['python'].prefix.lib64` (see #2295 and #2253). On my CentOS 6 machine, the Python libraries are installed in `/usr/lib64`. Both need to work.
The libraries themselves change name depending on OS and Python version. For Python 2.7 on macOS, I'm seeing:
```
lib/libpython2.7.dylib
```
For Python 3.6 on CentOS 6, I'm seeing:
```
lib/libpython3.so
lib/libpython3.6m.so.1.0
lib/libpython3.6m.so -> lib/libpython3.6m.so.1.0
```
Notice the `m` after the version number. Yeah, that's a thing.
## Headers
In Python 2.7, I'm seeing:
```
include/python2.7/pyconfig.h
```
In Python 3.6, I'm seeing:
```
include/python3.6m/pyconfig.h
```
It looks like all Python 3 installations have this `m`. Tested with Python 3.2 and 3.6 on macOS and CentOS 6
Spack has really nice support for libraries (`find_libraries` and `LibraryList`), but nothing for headers. Fixed.
2017-04-30 08:24:13 +08:00
|
|
|
cf = self.command('-c', sc, output=str).strip()
|
2017-01-24 01:34:50 +08:00
|
|
|
self.sysconfigfilename = '{0}.py'.format(cf)
|
|
|
|
|
2016-12-09 17:18:10 +08:00
|
|
|
self._save_distutil_vars(prefix)
|
2016-12-08 20:39:10 +08:00
|
|
|
|
2016-12-08 20:36:18 +08:00
|
|
|
self.filter_compilers(prefix)
|
2016-06-18 02:33:09 +08:00
|
|
|
|
2016-11-16 22:29:08 +08:00
|
|
|
# TODO:
|
|
|
|
# On OpenSuse 13, python uses <prefix>/lib64/python2.7/lib-dynload/*.so
|
|
|
|
# instead of <prefix>/lib/python2.7/lib-dynload/*.so. Oddly enough the
|
|
|
|
# result is that Python can not find modules like cPickle. A workaround
|
|
|
|
# for now is to symlink to `lib`:
|
2016-12-08 20:36:18 +08:00
|
|
|
src = os.path.join(prefix.lib64,
|
2016-11-16 22:29:08 +08:00
|
|
|
'python{0}'.format(self.version.up_to(2)),
|
|
|
|
'lib-dynload')
|
2016-12-08 20:36:18 +08:00
|
|
|
dst = os.path.join(prefix.lib,
|
2016-11-16 22:29:08 +08:00
|
|
|
'python{0}'.format(self.version.up_to(2)),
|
|
|
|
'lib-dynload')
|
|
|
|
if os.path.isdir(src) and not os.path.isdir(dst):
|
|
|
|
mkdirp(dst)
|
|
|
|
for f in os.listdir(src):
|
|
|
|
os.symlink(os.path.join(src, f),
|
|
|
|
os.path.join(dst, f))
|
|
|
|
|
2016-07-13 00:38:13 +08:00
|
|
|
# TODO: Once better testing support is integrated, add the following tests
|
|
|
|
# https://wiki.python.org/moin/TkInter
|
|
|
|
#
|
2016-08-04 01:35:09 +08:00
|
|
|
# Note: Only works if ForwardX11Trusted is enabled, i.e. `ssh -Y`
|
|
|
|
#
|
2016-07-13 00:38:13 +08:00
|
|
|
# if '+tk' in spec:
|
|
|
|
# env['TK_LIBRARY'] = join_path(spec['tk'].prefix.lib,
|
|
|
|
# 'tk{0}'.format(spec['tk'].version.up_to(2)))
|
|
|
|
# env['TCL_LIBRARY'] = join_path(spec['tcl'].prefix.lib,
|
|
|
|
# 'tcl{0}'.format(spec['tcl'].version.up_to(2)))
|
|
|
|
#
|
|
|
|
# $ python
|
|
|
|
# >>> import _tkinter
|
|
|
|
#
|
|
|
|
# if spec.satisfies('@3:')
|
|
|
|
# >>> import tkinter
|
|
|
|
# >>> tkinter._test()
|
|
|
|
# else:
|
|
|
|
# >>> import Tkinter
|
|
|
|
# >>> Tkinter._test()
|
|
|
|
|
2016-12-09 17:18:10 +08:00
|
|
|
def _save_distutil_vars(self, prefix):
|
2016-12-08 20:39:10 +08:00
|
|
|
"""
|
|
|
|
Run before changing automatically generated contents of the
|
|
|
|
_sysconfigdata.py, which is used by distutils to figure out what
|
|
|
|
executables to use while compiling and linking extensions. If we build
|
|
|
|
extensions with spack those executables should be spack's wrappers.
|
|
|
|
Spack partially covers this by setting environment variables that
|
|
|
|
are also accounted for by distutils. Currently there is one more known
|
|
|
|
variable that must be set, which is LDSHARED, so the method saves its
|
Python command, libraries, and headers (#3367)
## Motivation
Python installations are both important and unfortunately inconsistent. Depending on the Python version, OS, and the strength of the Earth's magnetic field when it was installed, the name of the Python executable, directory containing its libraries, library names, and the directory containing its headers can vary drastically.
I originally got into this mess with #3274, where I discovered that Boost could not be built with Python 3 because the executable is called `python3` and we were telling it to use `python`. I got deeper into this mess when I started hacking on #3140, where I discovered just how difficult it is to find the location and name of the Python libraries and headers.
Currently, half of the packages that depend on Python and need to know this information jump through hoops to determine the correct information. The other half are hard-coded to use `python`, `spec['python'].prefix.lib`, and `spec['python'].prefix.include`. Obviously, none of these packages would work for Python 3, and there's no reason to duplicate the effort. The Python package itself should contain all of the information necessary to use it properly. This is in line with the recent work by @alalazo and @davydden with respect to `spec['blas'].libs` and friends.
## Prefix
For most packages in Spack, we assume that the installation directory is `spec['python'].prefix`. This generally works for anything installed with Spack, but gets complicated when we include external packages. Python is a commonly used external package (it needs to be installed just to run Spack). If it was installed with Homebrew, `which python` would return `/usr/local/bin/python`, and most users would erroneously assume that `/usr/local` is the installation directory. If you peruse through #2173, you'll immediately see why this is not the case. Homebrew actually installs Python in `/usr/local/Cellar/python/2.7.12_2` and symlinks the executable to `/usr/local/bin/python`. `PYTHONHOME` (and presumably most things that need to know where Python is installed) needs to be set to the actual installation directory, not `/usr/local`.
Normally I would say, "sounds like user error, make sure to use the real installation directory in your `packages.yaml`". But I think we can make a special case for Python. That's what we decided in #2173 anyway. If we change our minds, I would be more than happy to simplify things.
To solve this problem, I created a `spec['python'].home` attribute that works the same way as `spec['python'].prefix` but queries Python to figure out where it was actually installed. @tgamblin Is there any way to overwrite `spec['python'].prefix`? I think it's currently immutable.
## Command
In general, Python 2 comes with both `python` and `python2` commands, while Python 3 only comes with a `python3` command. But this is up to the OS developers. For example, `/usr/bin/python` on Gentoo is actually Python 3. Worse yet, if someone is using an externally installed Python, all 3 commands may exist in the same directory! Here's what I'm thinking:
If the spec is for Python 3, try searching for the `python3` command.
If the spec is for Python 2, try searching for the `python2` command.
If neither are found, try searching for the `python` command.
## Libraries
Spack installs Python libraries in `spec['python'].prefix.lib`. Except on openSUSE 13, where it installs to `spec['python'].prefix.lib64` (see #2295 and #2253). On my CentOS 6 machine, the Python libraries are installed in `/usr/lib64`. Both need to work.
The libraries themselves change name depending on OS and Python version. For Python 2.7 on macOS, I'm seeing:
```
lib/libpython2.7.dylib
```
For Python 3.6 on CentOS 6, I'm seeing:
```
lib/libpython3.so
lib/libpython3.6m.so.1.0
lib/libpython3.6m.so -> lib/libpython3.6m.so.1.0
```
Notice the `m` after the version number. Yeah, that's a thing.
## Headers
In Python 2.7, I'm seeing:
```
include/python2.7/pyconfig.h
```
In Python 3.6, I'm seeing:
```
include/python3.6m/pyconfig.h
```
It looks like all Python 3 installations have this `m`. Tested with Python 3.2 and 3.6 on macOS and CentOS 6
Spack has really nice support for libraries (`find_libraries` and `LibraryList`), but nothing for headers. Fixed.
2017-04-30 08:24:13 +08:00
|
|
|
autogenerated value to pass it to the dependent package's setup script.
|
2016-12-08 20:39:10 +08:00
|
|
|
"""
|
|
|
|
|
2016-12-09 17:18:10 +08:00
|
|
|
self._distutil_vars = {}
|
|
|
|
|
2016-12-08 20:39:10 +08:00
|
|
|
input_filename = None
|
|
|
|
for filename in [join_path(lib_dir,
|
|
|
|
'python{0}'.format(self.version.up_to(2)),
|
2017-01-24 01:34:50 +08:00
|
|
|
self.sysconfigfilename)
|
2016-12-08 20:39:10 +08:00
|
|
|
for lib_dir in [prefix.lib, prefix.lib64]]:
|
|
|
|
if os.path.isfile(filename):
|
|
|
|
input_filename = filename
|
|
|
|
break
|
|
|
|
if not input_filename:
|
|
|
|
return
|
|
|
|
|
|
|
|
input_dict = None
|
|
|
|
try:
|
|
|
|
with open(input_filename) as input_file:
|
|
|
|
match = re.search(r'build_time_vars\s*=\s*(?P<dict>{.*})',
|
|
|
|
input_file.read(),
|
|
|
|
flags=re.DOTALL)
|
|
|
|
|
|
|
|
if match:
|
|
|
|
input_dict = ast.literal_eval(match.group('dict'))
|
|
|
|
except (IOError, SyntaxError):
|
|
|
|
pass
|
|
|
|
|
|
|
|
if not input_dict:
|
Python command, libraries, and headers (#3367)
## Motivation
Python installations are both important and unfortunately inconsistent. Depending on the Python version, OS, and the strength of the Earth's magnetic field when it was installed, the name of the Python executable, directory containing its libraries, library names, and the directory containing its headers can vary drastically.
I originally got into this mess with #3274, where I discovered that Boost could not be built with Python 3 because the executable is called `python3` and we were telling it to use `python`. I got deeper into this mess when I started hacking on #3140, where I discovered just how difficult it is to find the location and name of the Python libraries and headers.
Currently, half of the packages that depend on Python and need to know this information jump through hoops to determine the correct information. The other half are hard-coded to use `python`, `spec['python'].prefix.lib`, and `spec['python'].prefix.include`. Obviously, none of these packages would work for Python 3, and there's no reason to duplicate the effort. The Python package itself should contain all of the information necessary to use it properly. This is in line with the recent work by @alalazo and @davydden with respect to `spec['blas'].libs` and friends.
## Prefix
For most packages in Spack, we assume that the installation directory is `spec['python'].prefix`. This generally works for anything installed with Spack, but gets complicated when we include external packages. Python is a commonly used external package (it needs to be installed just to run Spack). If it was installed with Homebrew, `which python` would return `/usr/local/bin/python`, and most users would erroneously assume that `/usr/local` is the installation directory. If you peruse through #2173, you'll immediately see why this is not the case. Homebrew actually installs Python in `/usr/local/Cellar/python/2.7.12_2` and symlinks the executable to `/usr/local/bin/python`. `PYTHONHOME` (and presumably most things that need to know where Python is installed) needs to be set to the actual installation directory, not `/usr/local`.
Normally I would say, "sounds like user error, make sure to use the real installation directory in your `packages.yaml`". But I think we can make a special case for Python. That's what we decided in #2173 anyway. If we change our minds, I would be more than happy to simplify things.
To solve this problem, I created a `spec['python'].home` attribute that works the same way as `spec['python'].prefix` but queries Python to figure out where it was actually installed. @tgamblin Is there any way to overwrite `spec['python'].prefix`? I think it's currently immutable.
## Command
In general, Python 2 comes with both `python` and `python2` commands, while Python 3 only comes with a `python3` command. But this is up to the OS developers. For example, `/usr/bin/python` on Gentoo is actually Python 3. Worse yet, if someone is using an externally installed Python, all 3 commands may exist in the same directory! Here's what I'm thinking:
If the spec is for Python 3, try searching for the `python3` command.
If the spec is for Python 2, try searching for the `python2` command.
If neither are found, try searching for the `python` command.
## Libraries
Spack installs Python libraries in `spec['python'].prefix.lib`. Except on openSUSE 13, where it installs to `spec['python'].prefix.lib64` (see #2295 and #2253). On my CentOS 6 machine, the Python libraries are installed in `/usr/lib64`. Both need to work.
The libraries themselves change name depending on OS and Python version. For Python 2.7 on macOS, I'm seeing:
```
lib/libpython2.7.dylib
```
For Python 3.6 on CentOS 6, I'm seeing:
```
lib/libpython3.so
lib/libpython3.6m.so.1.0
lib/libpython3.6m.so -> lib/libpython3.6m.so.1.0
```
Notice the `m` after the version number. Yeah, that's a thing.
## Headers
In Python 2.7, I'm seeing:
```
include/python2.7/pyconfig.h
```
In Python 3.6, I'm seeing:
```
include/python3.6m/pyconfig.h
```
It looks like all Python 3 installations have this `m`. Tested with Python 3.2 and 3.6 on macOS and CentOS 6
Spack has really nice support for libraries (`find_libraries` and `LibraryList`), but nothing for headers. Fixed.
2017-04-30 08:24:13 +08:00
|
|
|
tty.warn("Failed to find 'build_time_vars' dictionary in file "
|
|
|
|
"'%s'. This might cause the extensions that are "
|
|
|
|
"installed with distutils to call compilers directly "
|
|
|
|
"avoiding Spack's wrappers." % input_filename)
|
2016-12-08 20:39:10 +08:00
|
|
|
return
|
|
|
|
|
2016-12-09 17:18:10 +08:00
|
|
|
for var_name in Python._DISTUTIL_VARS_TO_SAVE:
|
2016-12-08 20:39:10 +08:00
|
|
|
if var_name in input_dict:
|
2016-12-09 17:18:10 +08:00
|
|
|
self._distutil_vars[var_name] = input_dict[var_name]
|
|
|
|
else:
|
Python command, libraries, and headers (#3367)
## Motivation
Python installations are both important and unfortunately inconsistent. Depending on the Python version, OS, and the strength of the Earth's magnetic field when it was installed, the name of the Python executable, directory containing its libraries, library names, and the directory containing its headers can vary drastically.
I originally got into this mess with #3274, where I discovered that Boost could not be built with Python 3 because the executable is called `python3` and we were telling it to use `python`. I got deeper into this mess when I started hacking on #3140, where I discovered just how difficult it is to find the location and name of the Python libraries and headers.
Currently, half of the packages that depend on Python and need to know this information jump through hoops to determine the correct information. The other half are hard-coded to use `python`, `spec['python'].prefix.lib`, and `spec['python'].prefix.include`. Obviously, none of these packages would work for Python 3, and there's no reason to duplicate the effort. The Python package itself should contain all of the information necessary to use it properly. This is in line with the recent work by @alalazo and @davydden with respect to `spec['blas'].libs` and friends.
## Prefix
For most packages in Spack, we assume that the installation directory is `spec['python'].prefix`. This generally works for anything installed with Spack, but gets complicated when we include external packages. Python is a commonly used external package (it needs to be installed just to run Spack). If it was installed with Homebrew, `which python` would return `/usr/local/bin/python`, and most users would erroneously assume that `/usr/local` is the installation directory. If you peruse through #2173, you'll immediately see why this is not the case. Homebrew actually installs Python in `/usr/local/Cellar/python/2.7.12_2` and symlinks the executable to `/usr/local/bin/python`. `PYTHONHOME` (and presumably most things that need to know where Python is installed) needs to be set to the actual installation directory, not `/usr/local`.
Normally I would say, "sounds like user error, make sure to use the real installation directory in your `packages.yaml`". But I think we can make a special case for Python. That's what we decided in #2173 anyway. If we change our minds, I would be more than happy to simplify things.
To solve this problem, I created a `spec['python'].home` attribute that works the same way as `spec['python'].prefix` but queries Python to figure out where it was actually installed. @tgamblin Is there any way to overwrite `spec['python'].prefix`? I think it's currently immutable.
## Command
In general, Python 2 comes with both `python` and `python2` commands, while Python 3 only comes with a `python3` command. But this is up to the OS developers. For example, `/usr/bin/python` on Gentoo is actually Python 3. Worse yet, if someone is using an externally installed Python, all 3 commands may exist in the same directory! Here's what I'm thinking:
If the spec is for Python 3, try searching for the `python3` command.
If the spec is for Python 2, try searching for the `python2` command.
If neither are found, try searching for the `python` command.
## Libraries
Spack installs Python libraries in `spec['python'].prefix.lib`. Except on openSUSE 13, where it installs to `spec['python'].prefix.lib64` (see #2295 and #2253). On my CentOS 6 machine, the Python libraries are installed in `/usr/lib64`. Both need to work.
The libraries themselves change name depending on OS and Python version. For Python 2.7 on macOS, I'm seeing:
```
lib/libpython2.7.dylib
```
For Python 3.6 on CentOS 6, I'm seeing:
```
lib/libpython3.so
lib/libpython3.6m.so.1.0
lib/libpython3.6m.so -> lib/libpython3.6m.so.1.0
```
Notice the `m` after the version number. Yeah, that's a thing.
## Headers
In Python 2.7, I'm seeing:
```
include/python2.7/pyconfig.h
```
In Python 3.6, I'm seeing:
```
include/python3.6m/pyconfig.h
```
It looks like all Python 3 installations have this `m`. Tested with Python 3.2 and 3.6 on macOS and CentOS 6
Spack has really nice support for libraries (`find_libraries` and `LibraryList`), but nothing for headers. Fixed.
2017-04-30 08:24:13 +08:00
|
|
|
tty.warn("Failed to find key '%s' in 'build_time_vars' "
|
|
|
|
"dictionary in file '%s'. This might cause the "
|
|
|
|
"extensions that are installed with distutils to "
|
|
|
|
"call compilers directly avoiding Spack's wrappers."
|
2016-12-09 17:18:10 +08:00
|
|
|
% (var_name, input_filename))
|
|
|
|
|
|
|
|
if len(self._distutil_vars) > 0:
|
|
|
|
output_filename = None
|
2016-12-08 20:39:10 +08:00
|
|
|
try:
|
|
|
|
output_filename = join_path(
|
|
|
|
spack.store.layout.metadata_path(self.spec),
|
2016-12-09 17:18:10 +08:00
|
|
|
Python._DISTUTIL_CACHE_FILENAME)
|
2016-12-08 20:39:10 +08:00
|
|
|
with open(output_filename, 'w') as output_file:
|
2016-12-09 17:18:10 +08:00
|
|
|
sjson.dump(self._distutil_vars, output_file)
|
2017-10-23 22:51:11 +08:00
|
|
|
except Exception:
|
Python command, libraries, and headers (#3367)
## Motivation
Python installations are both important and unfortunately inconsistent. Depending on the Python version, OS, and the strength of the Earth's magnetic field when it was installed, the name of the Python executable, directory containing its libraries, library names, and the directory containing its headers can vary drastically.
I originally got into this mess with #3274, where I discovered that Boost could not be built with Python 3 because the executable is called `python3` and we were telling it to use `python`. I got deeper into this mess when I started hacking on #3140, where I discovered just how difficult it is to find the location and name of the Python libraries and headers.
Currently, half of the packages that depend on Python and need to know this information jump through hoops to determine the correct information. The other half are hard-coded to use `python`, `spec['python'].prefix.lib`, and `spec['python'].prefix.include`. Obviously, none of these packages would work for Python 3, and there's no reason to duplicate the effort. The Python package itself should contain all of the information necessary to use it properly. This is in line with the recent work by @alalazo and @davydden with respect to `spec['blas'].libs` and friends.
## Prefix
For most packages in Spack, we assume that the installation directory is `spec['python'].prefix`. This generally works for anything installed with Spack, but gets complicated when we include external packages. Python is a commonly used external package (it needs to be installed just to run Spack). If it was installed with Homebrew, `which python` would return `/usr/local/bin/python`, and most users would erroneously assume that `/usr/local` is the installation directory. If you peruse through #2173, you'll immediately see why this is not the case. Homebrew actually installs Python in `/usr/local/Cellar/python/2.7.12_2` and symlinks the executable to `/usr/local/bin/python`. `PYTHONHOME` (and presumably most things that need to know where Python is installed) needs to be set to the actual installation directory, not `/usr/local`.
Normally I would say, "sounds like user error, make sure to use the real installation directory in your `packages.yaml`". But I think we can make a special case for Python. That's what we decided in #2173 anyway. If we change our minds, I would be more than happy to simplify things.
To solve this problem, I created a `spec['python'].home` attribute that works the same way as `spec['python'].prefix` but queries Python to figure out where it was actually installed. @tgamblin Is there any way to overwrite `spec['python'].prefix`? I think it's currently immutable.
## Command
In general, Python 2 comes with both `python` and `python2` commands, while Python 3 only comes with a `python3` command. But this is up to the OS developers. For example, `/usr/bin/python` on Gentoo is actually Python 3. Worse yet, if someone is using an externally installed Python, all 3 commands may exist in the same directory! Here's what I'm thinking:
If the spec is for Python 3, try searching for the `python3` command.
If the spec is for Python 2, try searching for the `python2` command.
If neither are found, try searching for the `python` command.
## Libraries
Spack installs Python libraries in `spec['python'].prefix.lib`. Except on openSUSE 13, where it installs to `spec['python'].prefix.lib64` (see #2295 and #2253). On my CentOS 6 machine, the Python libraries are installed in `/usr/lib64`. Both need to work.
The libraries themselves change name depending on OS and Python version. For Python 2.7 on macOS, I'm seeing:
```
lib/libpython2.7.dylib
```
For Python 3.6 on CentOS 6, I'm seeing:
```
lib/libpython3.so
lib/libpython3.6m.so.1.0
lib/libpython3.6m.so -> lib/libpython3.6m.so.1.0
```
Notice the `m` after the version number. Yeah, that's a thing.
## Headers
In Python 2.7, I'm seeing:
```
include/python2.7/pyconfig.h
```
In Python 3.6, I'm seeing:
```
include/python3.6m/pyconfig.h
```
It looks like all Python 3 installations have this `m`. Tested with Python 3.2 and 3.6 on macOS and CentOS 6
Spack has really nice support for libraries (`find_libraries` and `LibraryList`), but nothing for headers. Fixed.
2017-04-30 08:24:13 +08:00
|
|
|
tty.warn("Failed to save metadata for distutils. This might "
|
|
|
|
"cause the extensions that are installed with "
|
|
|
|
"distutils to call compilers directly avoiding "
|
|
|
|
"Spack's wrappers.")
|
2016-12-09 17:18:10 +08:00
|
|
|
# We make the cache empty if we failed to save it to file
|
|
|
|
# to provide the same behaviour as in the case when the cache
|
|
|
|
# is initialized by the method load_distutils_data().
|
|
|
|
self._distutil_vars = {}
|
|
|
|
if output_filename:
|
|
|
|
force_remove(output_filename)
|
|
|
|
|
|
|
|
def _load_distutil_vars(self):
|
|
|
|
# We update and keep the cache unchanged only if the package is
|
|
|
|
# installed.
|
|
|
|
if not self._distutil_vars and self.installed:
|
|
|
|
try:
|
|
|
|
input_filename = join_path(
|
|
|
|
spack.store.layout.metadata_path(self.spec),
|
|
|
|
Python._DISTUTIL_CACHE_FILENAME)
|
|
|
|
if os.path.isfile(input_filename):
|
|
|
|
with open(input_filename) as input_file:
|
|
|
|
self._distutil_vars = sjson.load(input_file)
|
2017-10-23 22:51:11 +08:00
|
|
|
except Exception:
|
2016-12-08 20:39:10 +08:00
|
|
|
pass
|
|
|
|
|
2016-12-09 17:18:10 +08:00
|
|
|
if not self._distutil_vars:
|
|
|
|
self._distutil_vars = {}
|
2016-12-08 20:39:10 +08:00
|
|
|
|
2016-12-09 17:18:10 +08:00
|
|
|
return self._distutil_vars
|
2016-12-08 20:39:10 +08:00
|
|
|
|
2016-12-08 20:36:18 +08:00
|
|
|
def filter_compilers(self, prefix):
|
2016-06-18 02:33:09 +08:00
|
|
|
"""Run after install to tell the configuration files and Makefiles
|
|
|
|
to use the compilers that Spack built the package with.
|
|
|
|
|
|
|
|
If this isn't done, they'll have CC and CXX set to Spack's generic
|
|
|
|
cc and c++. We want them to be bound to whatever compiler
|
|
|
|
they were built with."""
|
|
|
|
|
|
|
|
kwargs = {'ignore_absent': True, 'backup': False, 'string': True}
|
2016-02-19 07:45:29 +08:00
|
|
|
|
2016-12-08 20:36:18 +08:00
|
|
|
lib_dirnames = [
|
|
|
|
join_path(lib_dir, 'python{0}'.format(self.version.up_to(2))) for
|
|
|
|
lib_dir in [prefix.lib, prefix.lib64]]
|
2016-06-18 02:33:09 +08:00
|
|
|
|
2016-12-08 20:36:18 +08:00
|
|
|
config_dirname = 'config-{0}m'.format(
|
|
|
|
self.version.up_to(2)) if self.spec.satisfies('@3:') else 'config'
|
2016-06-18 02:33:09 +08:00
|
|
|
|
2017-01-24 01:34:50 +08:00
|
|
|
rel_filenames = [self.sysconfigfilename,
|
2016-12-08 20:36:18 +08:00
|
|
|
join_path(config_dirname, 'Makefile')]
|
|
|
|
|
|
|
|
abs_filenames = [join_path(dirname, filename) for dirname in
|
|
|
|
lib_dirnames for filename in rel_filenames]
|
2016-02-19 07:45:29 +08:00
|
|
|
|
2016-12-08 20:36:18 +08:00
|
|
|
filter_file(env['CC'], self.compiler.cc, *abs_filenames, **kwargs)
|
|
|
|
filter_file(env['CXX'], self.compiler.cxx, *abs_filenames, **kwargs)
|
2015-01-11 11:37:01 +08:00
|
|
|
|
2015-02-02 22:09:35 +08:00
|
|
|
# ========================================================================
|
|
|
|
# Set up environment to make install easy for python extensions.
|
|
|
|
# ========================================================================
|
|
|
|
|
Python command, libraries, and headers (#3367)
## Motivation
Python installations are both important and unfortunately inconsistent. Depending on the Python version, OS, and the strength of the Earth's magnetic field when it was installed, the name of the Python executable, directory containing its libraries, library names, and the directory containing its headers can vary drastically.
I originally got into this mess with #3274, where I discovered that Boost could not be built with Python 3 because the executable is called `python3` and we were telling it to use `python`. I got deeper into this mess when I started hacking on #3140, where I discovered just how difficult it is to find the location and name of the Python libraries and headers.
Currently, half of the packages that depend on Python and need to know this information jump through hoops to determine the correct information. The other half are hard-coded to use `python`, `spec['python'].prefix.lib`, and `spec['python'].prefix.include`. Obviously, none of these packages would work for Python 3, and there's no reason to duplicate the effort. The Python package itself should contain all of the information necessary to use it properly. This is in line with the recent work by @alalazo and @davydden with respect to `spec['blas'].libs` and friends.
## Prefix
For most packages in Spack, we assume that the installation directory is `spec['python'].prefix`. This generally works for anything installed with Spack, but gets complicated when we include external packages. Python is a commonly used external package (it needs to be installed just to run Spack). If it was installed with Homebrew, `which python` would return `/usr/local/bin/python`, and most users would erroneously assume that `/usr/local` is the installation directory. If you peruse through #2173, you'll immediately see why this is not the case. Homebrew actually installs Python in `/usr/local/Cellar/python/2.7.12_2` and symlinks the executable to `/usr/local/bin/python`. `PYTHONHOME` (and presumably most things that need to know where Python is installed) needs to be set to the actual installation directory, not `/usr/local`.
Normally I would say, "sounds like user error, make sure to use the real installation directory in your `packages.yaml`". But I think we can make a special case for Python. That's what we decided in #2173 anyway. If we change our minds, I would be more than happy to simplify things.
To solve this problem, I created a `spec['python'].home` attribute that works the same way as `spec['python'].prefix` but queries Python to figure out where it was actually installed. @tgamblin Is there any way to overwrite `spec['python'].prefix`? I think it's currently immutable.
## Command
In general, Python 2 comes with both `python` and `python2` commands, while Python 3 only comes with a `python3` command. But this is up to the OS developers. For example, `/usr/bin/python` on Gentoo is actually Python 3. Worse yet, if someone is using an externally installed Python, all 3 commands may exist in the same directory! Here's what I'm thinking:
If the spec is for Python 3, try searching for the `python3` command.
If the spec is for Python 2, try searching for the `python2` command.
If neither are found, try searching for the `python` command.
## Libraries
Spack installs Python libraries in `spec['python'].prefix.lib`. Except on openSUSE 13, where it installs to `spec['python'].prefix.lib64` (see #2295 and #2253). On my CentOS 6 machine, the Python libraries are installed in `/usr/lib64`. Both need to work.
The libraries themselves change name depending on OS and Python version. For Python 2.7 on macOS, I'm seeing:
```
lib/libpython2.7.dylib
```
For Python 3.6 on CentOS 6, I'm seeing:
```
lib/libpython3.so
lib/libpython3.6m.so.1.0
lib/libpython3.6m.so -> lib/libpython3.6m.so.1.0
```
Notice the `m` after the version number. Yeah, that's a thing.
## Headers
In Python 2.7, I'm seeing:
```
include/python2.7/pyconfig.h
```
In Python 3.6, I'm seeing:
```
include/python3.6m/pyconfig.h
```
It looks like all Python 3 installations have this `m`. Tested with Python 3.2 and 3.6 on macOS and CentOS 6
Spack has really nice support for libraries (`find_libraries` and `LibraryList`), but nothing for headers. Fixed.
2017-04-30 08:24:13 +08:00
|
|
|
@property
|
|
|
|
def command(self):
|
|
|
|
"""Returns the Python command, which may vary depending
|
|
|
|
on the version of Python and how it was installed.
|
|
|
|
|
|
|
|
In general, Python 2 comes with ``python`` and ``python2`` commands,
|
|
|
|
while Python 3 only comes with a ``python3`` command.
|
|
|
|
|
|
|
|
:returns: The Python command
|
|
|
|
:rtype: Executable
|
|
|
|
"""
|
|
|
|
# We need to be careful here. If the user is using an externally
|
|
|
|
# installed python, all 3 commands could be in the same directory.
|
|
|
|
|
|
|
|
# Search for `python2` iff using Python 2
|
|
|
|
if (self.spec.satisfies('@:2') and
|
|
|
|
os.path.exists(os.path.join(self.prefix.bin, 'python2'))):
|
|
|
|
command = 'python2'
|
|
|
|
# Search for `python3` iff using Python 3
|
|
|
|
elif (self.spec.satisfies('@3:') and
|
|
|
|
os.path.exists(os.path.join(self.prefix.bin, 'python3'))):
|
|
|
|
command = 'python3'
|
|
|
|
# If neither were found, try `python`
|
|
|
|
elif os.path.exists(os.path.join(self.prefix.bin, 'python')):
|
|
|
|
command = 'python'
|
|
|
|
else:
|
|
|
|
msg = 'Unable to locate {0} command in {1}'
|
|
|
|
raise RuntimeError(msg.format(self.name, self.prefix.bin))
|
|
|
|
|
|
|
|
# The python command may be a symlink if it was installed
|
|
|
|
# with Homebrew. Since some packages try to determine the
|
|
|
|
# location of libraries and headers based on the path,
|
|
|
|
# return the realpath
|
|
|
|
path = os.path.realpath(os.path.join(self.prefix.bin, command))
|
|
|
|
|
|
|
|
return Executable(path)
|
|
|
|
|
|
|
|
def print_string(self, string):
|
|
|
|
"""Returns the appropriate print string depending on the
|
|
|
|
version of Python.
|
|
|
|
|
|
|
|
Examples:
|
|
|
|
|
|
|
|
* Python 2
|
|
|
|
|
|
|
|
.. code-block:: python
|
|
|
|
|
|
|
|
>>> self.print_string('sys.prefix')
|
|
|
|
'print sys.prefix'
|
|
|
|
|
|
|
|
* Python 3
|
|
|
|
|
|
|
|
.. code-block:: python
|
|
|
|
|
|
|
|
>>> self.print_string('sys.prefix')
|
|
|
|
'print(sys.prefix)'
|
|
|
|
"""
|
|
|
|
if self.spec.satisfies('@:2'):
|
|
|
|
return 'print {0}'.format(string)
|
|
|
|
else:
|
|
|
|
return 'print({0})'.format(string)
|
|
|
|
|
|
|
|
def get_config_var(self, key):
|
|
|
|
"""Returns the value of a single variable. Wrapper around
|
|
|
|
``distutils.sysconfig.get_config_var()``."""
|
|
|
|
|
|
|
|
cmd = 'from distutils.sysconfig import get_config_var; '
|
|
|
|
cmd += self.print_string("get_config_var('{0}')".format(key))
|
|
|
|
|
|
|
|
return self.command('-c', cmd, output=str).strip()
|
|
|
|
|
|
|
|
def get_config_h_filename(self):
|
|
|
|
"""Returns the full path name of the configuration header.
|
|
|
|
Wrapper around ``distutils.sysconfig.get_config_h_filename()``."""
|
|
|
|
|
|
|
|
cmd = 'from distutils.sysconfig import get_config_h_filename; '
|
|
|
|
cmd += self.print_string('get_config_h_filename()')
|
|
|
|
|
|
|
|
return self.command('-c', cmd, output=str).strip()
|
|
|
|
|
|
|
|
@property
|
|
|
|
def home(self):
|
|
|
|
"""Most of the time, ``PYTHONHOME`` is simply
|
|
|
|
``spec['python'].prefix``. However, if the user is using an
|
|
|
|
externally installed python, it may be symlinked. For example,
|
|
|
|
Homebrew installs python in ``/usr/local/Cellar/python/2.7.12_2``
|
|
|
|
and symlinks it to ``/usr/local``. Users may not know the actual
|
|
|
|
installation directory and add ``/usr/local`` to their
|
|
|
|
``packages.yaml`` unknowingly. Query the python executable to
|
|
|
|
determine exactly where it is installed."""
|
|
|
|
|
|
|
|
prefix = self.get_config_var('prefix')
|
|
|
|
return Prefix(prefix)
|
|
|
|
|
|
|
|
@property
|
|
|
|
def libs(self):
|
|
|
|
# Spack installs libraries into lib, except on openSUSE where it
|
|
|
|
# installs them into lib64. If the user is using an externally
|
|
|
|
# installed package, it may be in either lib or lib64, so we need
|
|
|
|
# to ask Python where its LIBDIR is.
|
|
|
|
libdir = self.get_config_var('LIBDIR')
|
|
|
|
|
|
|
|
# The system Python installation on macOS and Homebrew installations
|
|
|
|
# install libraries into a Frameworks directory
|
|
|
|
frameworkprefix = self.get_config_var('PYTHONFRAMEWORKPREFIX')
|
|
|
|
|
|
|
|
if '+shared' in self.spec:
|
|
|
|
ldlibrary = self.get_config_var('LDLIBRARY')
|
|
|
|
|
|
|
|
if os.path.exists(os.path.join(libdir, ldlibrary)):
|
|
|
|
return LibraryList(os.path.join(libdir, ldlibrary))
|
|
|
|
elif os.path.exists(os.path.join(frameworkprefix, ldlibrary)):
|
|
|
|
return LibraryList(os.path.join(frameworkprefix, ldlibrary))
|
|
|
|
else:
|
|
|
|
msg = 'Unable to locate {0} libraries in {1}'
|
|
|
|
raise RuntimeError(msg.format(self.name, libdir))
|
|
|
|
else:
|
|
|
|
library = self.get_config_var('LIBRARY')
|
|
|
|
|
|
|
|
if os.path.exists(os.path.join(libdir, library)):
|
|
|
|
return LibraryList(os.path.join(libdir, library))
|
|
|
|
elif os.path.exists(os.path.join(frameworkprefix, library)):
|
|
|
|
return LibraryList(os.path.join(frameworkprefix, library))
|
|
|
|
else:
|
|
|
|
msg = 'Unable to locate {0} libraries in {1}'
|
|
|
|
raise RuntimeError(msg.format(self.name, libdir))
|
|
|
|
|
|
|
|
@property
|
|
|
|
def headers(self):
|
|
|
|
config_h = self.get_config_h_filename()
|
|
|
|
|
|
|
|
if os.path.exists(config_h):
|
|
|
|
return HeaderList(config_h)
|
|
|
|
else:
|
|
|
|
includepy = self.get_config_var('INCLUDEPY')
|
|
|
|
msg = 'Unable to locate {0} headers in {1}'
|
|
|
|
raise RuntimeError(msg.format(self.name, includepy))
|
|
|
|
|
2015-01-20 16:23:16 +08:00
|
|
|
@property
|
|
|
|
def python_lib_dir(self):
|
2016-06-18 02:33:09 +08:00
|
|
|
return join_path('lib', 'python{0}'.format(self.version.up_to(2)))
|
2015-01-20 16:23:16 +08:00
|
|
|
|
2015-02-15 17:59:36 +08:00
|
|
|
@property
|
|
|
|
def python_include_dir(self):
|
2016-06-18 02:33:09 +08:00
|
|
|
return join_path('include', 'python{0}'.format(self.version.up_to(2)))
|
2015-02-15 17:59:36 +08:00
|
|
|
|
2015-01-20 16:23:16 +08:00
|
|
|
@property
|
|
|
|
def site_packages_dir(self):
|
2016-06-18 02:33:09 +08:00
|
|
|
return join_path(self.python_lib_dir, 'site-packages')
|
2016-03-21 16:48:18 +08:00
|
|
|
|
2017-03-15 13:26:44 +08:00
|
|
|
def setup_dependent_environment(self, spack_env, run_env, dependent_spec):
|
Python command, libraries, and headers (#3367)
## Motivation
Python installations are both important and unfortunately inconsistent. Depending on the Python version, OS, and the strength of the Earth's magnetic field when it was installed, the name of the Python executable, directory containing its libraries, library names, and the directory containing its headers can vary drastically.
I originally got into this mess with #3274, where I discovered that Boost could not be built with Python 3 because the executable is called `python3` and we were telling it to use `python`. I got deeper into this mess when I started hacking on #3140, where I discovered just how difficult it is to find the location and name of the Python libraries and headers.
Currently, half of the packages that depend on Python and need to know this information jump through hoops to determine the correct information. The other half are hard-coded to use `python`, `spec['python'].prefix.lib`, and `spec['python'].prefix.include`. Obviously, none of these packages would work for Python 3, and there's no reason to duplicate the effort. The Python package itself should contain all of the information necessary to use it properly. This is in line with the recent work by @alalazo and @davydden with respect to `spec['blas'].libs` and friends.
## Prefix
For most packages in Spack, we assume that the installation directory is `spec['python'].prefix`. This generally works for anything installed with Spack, but gets complicated when we include external packages. Python is a commonly used external package (it needs to be installed just to run Spack). If it was installed with Homebrew, `which python` would return `/usr/local/bin/python`, and most users would erroneously assume that `/usr/local` is the installation directory. If you peruse through #2173, you'll immediately see why this is not the case. Homebrew actually installs Python in `/usr/local/Cellar/python/2.7.12_2` and symlinks the executable to `/usr/local/bin/python`. `PYTHONHOME` (and presumably most things that need to know where Python is installed) needs to be set to the actual installation directory, not `/usr/local`.
Normally I would say, "sounds like user error, make sure to use the real installation directory in your `packages.yaml`". But I think we can make a special case for Python. That's what we decided in #2173 anyway. If we change our minds, I would be more than happy to simplify things.
To solve this problem, I created a `spec['python'].home` attribute that works the same way as `spec['python'].prefix` but queries Python to figure out where it was actually installed. @tgamblin Is there any way to overwrite `spec['python'].prefix`? I think it's currently immutable.
## Command
In general, Python 2 comes with both `python` and `python2` commands, while Python 3 only comes with a `python3` command. But this is up to the OS developers. For example, `/usr/bin/python` on Gentoo is actually Python 3. Worse yet, if someone is using an externally installed Python, all 3 commands may exist in the same directory! Here's what I'm thinking:
If the spec is for Python 3, try searching for the `python3` command.
If the spec is for Python 2, try searching for the `python2` command.
If neither are found, try searching for the `python` command.
## Libraries
Spack installs Python libraries in `spec['python'].prefix.lib`. Except on openSUSE 13, where it installs to `spec['python'].prefix.lib64` (see #2295 and #2253). On my CentOS 6 machine, the Python libraries are installed in `/usr/lib64`. Both need to work.
The libraries themselves change name depending on OS and Python version. For Python 2.7 on macOS, I'm seeing:
```
lib/libpython2.7.dylib
```
For Python 3.6 on CentOS 6, I'm seeing:
```
lib/libpython3.so
lib/libpython3.6m.so.1.0
lib/libpython3.6m.so -> lib/libpython3.6m.so.1.0
```
Notice the `m` after the version number. Yeah, that's a thing.
## Headers
In Python 2.7, I'm seeing:
```
include/python2.7/pyconfig.h
```
In Python 3.6, I'm seeing:
```
include/python3.6m/pyconfig.h
```
It looks like all Python 3 installations have this `m`. Tested with Python 3.2 and 3.6 on macOS and CentOS 6
Spack has really nice support for libraries (`find_libraries` and `LibraryList`), but nothing for headers. Fixed.
2017-04-30 08:24:13 +08:00
|
|
|
"""Set PYTHONPATH to include the site-packages directory for the
|
2016-06-18 02:33:09 +08:00
|
|
|
extension and any other python extensions it depends on."""
|
Python command, libraries, and headers (#3367)
## Motivation
Python installations are both important and unfortunately inconsistent. Depending on the Python version, OS, and the strength of the Earth's magnetic field when it was installed, the name of the Python executable, directory containing its libraries, library names, and the directory containing its headers can vary drastically.
I originally got into this mess with #3274, where I discovered that Boost could not be built with Python 3 because the executable is called `python3` and we were telling it to use `python`. I got deeper into this mess when I started hacking on #3140, where I discovered just how difficult it is to find the location and name of the Python libraries and headers.
Currently, half of the packages that depend on Python and need to know this information jump through hoops to determine the correct information. The other half are hard-coded to use `python`, `spec['python'].prefix.lib`, and `spec['python'].prefix.include`. Obviously, none of these packages would work for Python 3, and there's no reason to duplicate the effort. The Python package itself should contain all of the information necessary to use it properly. This is in line with the recent work by @alalazo and @davydden with respect to `spec['blas'].libs` and friends.
## Prefix
For most packages in Spack, we assume that the installation directory is `spec['python'].prefix`. This generally works for anything installed with Spack, but gets complicated when we include external packages. Python is a commonly used external package (it needs to be installed just to run Spack). If it was installed with Homebrew, `which python` would return `/usr/local/bin/python`, and most users would erroneously assume that `/usr/local` is the installation directory. If you peruse through #2173, you'll immediately see why this is not the case. Homebrew actually installs Python in `/usr/local/Cellar/python/2.7.12_2` and symlinks the executable to `/usr/local/bin/python`. `PYTHONHOME` (and presumably most things that need to know where Python is installed) needs to be set to the actual installation directory, not `/usr/local`.
Normally I would say, "sounds like user error, make sure to use the real installation directory in your `packages.yaml`". But I think we can make a special case for Python. That's what we decided in #2173 anyway. If we change our minds, I would be more than happy to simplify things.
To solve this problem, I created a `spec['python'].home` attribute that works the same way as `spec['python'].prefix` but queries Python to figure out where it was actually installed. @tgamblin Is there any way to overwrite `spec['python'].prefix`? I think it's currently immutable.
## Command
In general, Python 2 comes with both `python` and `python2` commands, while Python 3 only comes with a `python3` command. But this is up to the OS developers. For example, `/usr/bin/python` on Gentoo is actually Python 3. Worse yet, if someone is using an externally installed Python, all 3 commands may exist in the same directory! Here's what I'm thinking:
If the spec is for Python 3, try searching for the `python3` command.
If the spec is for Python 2, try searching for the `python2` command.
If neither are found, try searching for the `python` command.
## Libraries
Spack installs Python libraries in `spec['python'].prefix.lib`. Except on openSUSE 13, where it installs to `spec['python'].prefix.lib64` (see #2295 and #2253). On my CentOS 6 machine, the Python libraries are installed in `/usr/lib64`. Both need to work.
The libraries themselves change name depending on OS and Python version. For Python 2.7 on macOS, I'm seeing:
```
lib/libpython2.7.dylib
```
For Python 3.6 on CentOS 6, I'm seeing:
```
lib/libpython3.so
lib/libpython3.6m.so.1.0
lib/libpython3.6m.so -> lib/libpython3.6m.so.1.0
```
Notice the `m` after the version number. Yeah, that's a thing.
## Headers
In Python 2.7, I'm seeing:
```
include/python2.7/pyconfig.h
```
In Python 3.6, I'm seeing:
```
include/python3.6m/pyconfig.h
```
It looks like all Python 3 installations have this `m`. Tested with Python 3.2 and 3.6 on macOS and CentOS 6
Spack has really nice support for libraries (`find_libraries` and `LibraryList`), but nothing for headers. Fixed.
2017-04-30 08:24:13 +08:00
|
|
|
|
|
|
|
spack_env.set('PYTHONHOME', self.home)
|
2016-03-21 16:48:18 +08:00
|
|
|
|
2016-03-17 22:11:39 +08:00
|
|
|
python_paths = []
|
2017-03-15 13:26:44 +08:00
|
|
|
for d in dependent_spec.traverse(
|
2017-01-08 11:59:02 +08:00
|
|
|
deptype=('build', 'run'), deptype_query='run'):
|
2016-03-17 22:11:39 +08:00
|
|
|
if d.package.extends(self.spec):
|
2016-06-18 02:33:09 +08:00
|
|
|
python_paths.append(join_path(d.prefix,
|
|
|
|
self.site_packages_dir))
|
2016-03-21 16:48:18 +08:00
|
|
|
|
|
|
|
pythonpath = ':'.join(python_paths)
|
2016-03-21 17:21:31 +08:00
|
|
|
spack_env.set('PYTHONPATH', pythonpath)
|
2016-03-23 18:18:11 +08:00
|
|
|
|
2016-06-18 02:33:09 +08:00
|
|
|
# For run time environment set only the path for
|
2017-03-15 13:26:44 +08:00
|
|
|
# dependent_spec and prepend it to PYTHONPATH
|
|
|
|
if dependent_spec.package.extends(self.spec):
|
2016-06-18 02:33:09 +08:00
|
|
|
run_env.prepend_path('PYTHONPATH', join_path(
|
2017-03-15 13:26:44 +08:00
|
|
|
dependent_spec.prefix, self.site_packages_dir))
|
2016-03-17 22:11:39 +08:00
|
|
|
|
2017-03-15 13:26:44 +08:00
|
|
|
def setup_dependent_package(self, module, dependent_spec):
|
2016-06-18 02:33:09 +08:00
|
|
|
"""Called before python modules' install() methods.
|
2015-01-11 11:37:01 +08:00
|
|
|
|
|
|
|
In most cases, extensions will only need to have one line::
|
|
|
|
|
2016-07-23 02:08:08 +08:00
|
|
|
setup_py('install', '--prefix={0}'.format(prefix))"""
|
2016-06-18 02:33:09 +08:00
|
|
|
|
Python command, libraries, and headers (#3367)
## Motivation
Python installations are both important and unfortunately inconsistent. Depending on the Python version, OS, and the strength of the Earth's magnetic field when it was installed, the name of the Python executable, directory containing its libraries, library names, and the directory containing its headers can vary drastically.
I originally got into this mess with #3274, where I discovered that Boost could not be built with Python 3 because the executable is called `python3` and we were telling it to use `python`. I got deeper into this mess when I started hacking on #3140, where I discovered just how difficult it is to find the location and name of the Python libraries and headers.
Currently, half of the packages that depend on Python and need to know this information jump through hoops to determine the correct information. The other half are hard-coded to use `python`, `spec['python'].prefix.lib`, and `spec['python'].prefix.include`. Obviously, none of these packages would work for Python 3, and there's no reason to duplicate the effort. The Python package itself should contain all of the information necessary to use it properly. This is in line with the recent work by @alalazo and @davydden with respect to `spec['blas'].libs` and friends.
## Prefix
For most packages in Spack, we assume that the installation directory is `spec['python'].prefix`. This generally works for anything installed with Spack, but gets complicated when we include external packages. Python is a commonly used external package (it needs to be installed just to run Spack). If it was installed with Homebrew, `which python` would return `/usr/local/bin/python`, and most users would erroneously assume that `/usr/local` is the installation directory. If you peruse through #2173, you'll immediately see why this is not the case. Homebrew actually installs Python in `/usr/local/Cellar/python/2.7.12_2` and symlinks the executable to `/usr/local/bin/python`. `PYTHONHOME` (and presumably most things that need to know where Python is installed) needs to be set to the actual installation directory, not `/usr/local`.
Normally I would say, "sounds like user error, make sure to use the real installation directory in your `packages.yaml`". But I think we can make a special case for Python. That's what we decided in #2173 anyway. If we change our minds, I would be more than happy to simplify things.
To solve this problem, I created a `spec['python'].home` attribute that works the same way as `spec['python'].prefix` but queries Python to figure out where it was actually installed. @tgamblin Is there any way to overwrite `spec['python'].prefix`? I think it's currently immutable.
## Command
In general, Python 2 comes with both `python` and `python2` commands, while Python 3 only comes with a `python3` command. But this is up to the OS developers. For example, `/usr/bin/python` on Gentoo is actually Python 3. Worse yet, if someone is using an externally installed Python, all 3 commands may exist in the same directory! Here's what I'm thinking:
If the spec is for Python 3, try searching for the `python3` command.
If the spec is for Python 2, try searching for the `python2` command.
If neither are found, try searching for the `python` command.
## Libraries
Spack installs Python libraries in `spec['python'].prefix.lib`. Except on openSUSE 13, where it installs to `spec['python'].prefix.lib64` (see #2295 and #2253). On my CentOS 6 machine, the Python libraries are installed in `/usr/lib64`. Both need to work.
The libraries themselves change name depending on OS and Python version. For Python 2.7 on macOS, I'm seeing:
```
lib/libpython2.7.dylib
```
For Python 3.6 on CentOS 6, I'm seeing:
```
lib/libpython3.so
lib/libpython3.6m.so.1.0
lib/libpython3.6m.so -> lib/libpython3.6m.so.1.0
```
Notice the `m` after the version number. Yeah, that's a thing.
## Headers
In Python 2.7, I'm seeing:
```
include/python2.7/pyconfig.h
```
In Python 3.6, I'm seeing:
```
include/python3.6m/pyconfig.h
```
It looks like all Python 3 installations have this `m`. Tested with Python 3.2 and 3.6 on macOS and CentOS 6
Spack has really nice support for libraries (`find_libraries` and `LibraryList`), but nothing for headers. Fixed.
2017-04-30 08:24:13 +08:00
|
|
|
module.python = self.command
|
|
|
|
module.setup_py = Executable(
|
|
|
|
self.command.path + ' setup.py --no-user-cfg')
|
2015-01-11 11:37:01 +08:00
|
|
|
|
2016-12-09 17:18:10 +08:00
|
|
|
distutil_vars = self._load_distutil_vars()
|
2016-12-08 20:39:10 +08:00
|
|
|
|
2016-12-09 17:18:10 +08:00
|
|
|
if distutil_vars:
|
Python command, libraries, and headers (#3367)
## Motivation
Python installations are both important and unfortunately inconsistent. Depending on the Python version, OS, and the strength of the Earth's magnetic field when it was installed, the name of the Python executable, directory containing its libraries, library names, and the directory containing its headers can vary drastically.
I originally got into this mess with #3274, where I discovered that Boost could not be built with Python 3 because the executable is called `python3` and we were telling it to use `python`. I got deeper into this mess when I started hacking on #3140, where I discovered just how difficult it is to find the location and name of the Python libraries and headers.
Currently, half of the packages that depend on Python and need to know this information jump through hoops to determine the correct information. The other half are hard-coded to use `python`, `spec['python'].prefix.lib`, and `spec['python'].prefix.include`. Obviously, none of these packages would work for Python 3, and there's no reason to duplicate the effort. The Python package itself should contain all of the information necessary to use it properly. This is in line with the recent work by @alalazo and @davydden with respect to `spec['blas'].libs` and friends.
## Prefix
For most packages in Spack, we assume that the installation directory is `spec['python'].prefix`. This generally works for anything installed with Spack, but gets complicated when we include external packages. Python is a commonly used external package (it needs to be installed just to run Spack). If it was installed with Homebrew, `which python` would return `/usr/local/bin/python`, and most users would erroneously assume that `/usr/local` is the installation directory. If you peruse through #2173, you'll immediately see why this is not the case. Homebrew actually installs Python in `/usr/local/Cellar/python/2.7.12_2` and symlinks the executable to `/usr/local/bin/python`. `PYTHONHOME` (and presumably most things that need to know where Python is installed) needs to be set to the actual installation directory, not `/usr/local`.
Normally I would say, "sounds like user error, make sure to use the real installation directory in your `packages.yaml`". But I think we can make a special case for Python. That's what we decided in #2173 anyway. If we change our minds, I would be more than happy to simplify things.
To solve this problem, I created a `spec['python'].home` attribute that works the same way as `spec['python'].prefix` but queries Python to figure out where it was actually installed. @tgamblin Is there any way to overwrite `spec['python'].prefix`? I think it's currently immutable.
## Command
In general, Python 2 comes with both `python` and `python2` commands, while Python 3 only comes with a `python3` command. But this is up to the OS developers. For example, `/usr/bin/python` on Gentoo is actually Python 3. Worse yet, if someone is using an externally installed Python, all 3 commands may exist in the same directory! Here's what I'm thinking:
If the spec is for Python 3, try searching for the `python3` command.
If the spec is for Python 2, try searching for the `python2` command.
If neither are found, try searching for the `python` command.
## Libraries
Spack installs Python libraries in `spec['python'].prefix.lib`. Except on openSUSE 13, where it installs to `spec['python'].prefix.lib64` (see #2295 and #2253). On my CentOS 6 machine, the Python libraries are installed in `/usr/lib64`. Both need to work.
The libraries themselves change name depending on OS and Python version. For Python 2.7 on macOS, I'm seeing:
```
lib/libpython2.7.dylib
```
For Python 3.6 on CentOS 6, I'm seeing:
```
lib/libpython3.so
lib/libpython3.6m.so.1.0
lib/libpython3.6m.so -> lib/libpython3.6m.so.1.0
```
Notice the `m` after the version number. Yeah, that's a thing.
## Headers
In Python 2.7, I'm seeing:
```
include/python2.7/pyconfig.h
```
In Python 3.6, I'm seeing:
```
include/python3.6m/pyconfig.h
```
It looks like all Python 3 installations have this `m`. Tested with Python 3.2 and 3.6 on macOS and CentOS 6
Spack has really nice support for libraries (`find_libraries` and `LibraryList`), but nothing for headers. Fixed.
2017-04-30 08:24:13 +08:00
|
|
|
for key, value in distutil_vars.items():
|
2016-12-08 20:39:10 +08:00
|
|
|
module.setup_py.add_default_env(key, value)
|
|
|
|
|
2015-01-11 11:37:01 +08:00
|
|
|
# Add variables for lib/pythonX.Y and lib/pythonX.Y/site-packages dirs.
|
2017-03-15 13:26:44 +08:00
|
|
|
module.python_lib_dir = join_path(dependent_spec.prefix,
|
2016-12-08 20:35:11 +08:00
|
|
|
self.python_lib_dir)
|
2017-03-15 13:26:44 +08:00
|
|
|
module.python_include_dir = join_path(dependent_spec.prefix,
|
2016-06-18 02:33:09 +08:00
|
|
|
self.python_include_dir)
|
2017-03-15 13:26:44 +08:00
|
|
|
module.site_packages_dir = join_path(dependent_spec.prefix,
|
2016-12-08 20:35:11 +08:00
|
|
|
self.site_packages_dir)
|
2016-06-18 02:33:09 +08:00
|
|
|
|
2017-05-19 01:12:08 +08:00
|
|
|
self.spec.home = self.home
|
|
|
|
|
2016-06-18 02:33:09 +08:00
|
|
|
# Make the site packages directory for extensions
|
2017-03-15 13:26:44 +08:00
|
|
|
if dependent_spec.package.is_extension:
|
2016-03-23 15:36:32 +08:00
|
|
|
mkdirp(module.site_packages_dir)
|
2015-01-20 16:23:16 +08:00
|
|
|
|
2015-02-02 22:09:35 +08:00
|
|
|
# ========================================================================
|
|
|
|
# Handle specifics of activating and deactivating python modules.
|
|
|
|
# ========================================================================
|
|
|
|
|
|
|
|
def python_ignore(self, ext_pkg, args):
|
2015-01-20 16:23:16 +08:00
|
|
|
"""Add some ignore files to activate/deactivate args."""
|
2015-02-17 16:21:15 +08:00
|
|
|
ignore_arg = args.get('ignore', lambda f: False)
|
2015-02-02 22:09:35 +08:00
|
|
|
|
2015-02-17 16:21:15 +08:00
|
|
|
# Always ignore easy-install.pth, as it needs to be merged.
|
2016-06-16 05:42:50 +08:00
|
|
|
patterns = [r'site-packages/easy-install\.pth$']
|
2015-02-02 22:09:35 +08:00
|
|
|
|
2015-02-17 16:21:15 +08:00
|
|
|
# Ignore pieces of setuptools installed by other packages.
|
2016-06-18 02:33:09 +08:00
|
|
|
# Must include directory name or it will remove all site*.py files.
|
2015-02-17 16:21:15 +08:00
|
|
|
if ext_pkg.name != 'py-setuptools':
|
2016-06-18 02:33:09 +08:00
|
|
|
patterns.extend([
|
|
|
|
r'bin/easy_install[^/]*$',
|
|
|
|
r'site-packages/setuptools[^/]*\.egg$',
|
|
|
|
r'site-packages/setuptools\.pth$',
|
|
|
|
r'site-packages/site[^/]*\.pyc?$',
|
|
|
|
r'site-packages/__pycache__/site[^/]*\.pyc?$'
|
|
|
|
])
|
2016-06-21 07:17:07 +08:00
|
|
|
if ext_pkg.name != 'py-pygments':
|
|
|
|
patterns.append(r'bin/pygmentize$')
|
2016-04-27 01:32:14 +08:00
|
|
|
if ext_pkg.name != 'py-numpy':
|
Python command, libraries, and headers (#3367)
## Motivation
Python installations are both important and unfortunately inconsistent. Depending on the Python version, OS, and the strength of the Earth's magnetic field when it was installed, the name of the Python executable, directory containing its libraries, library names, and the directory containing its headers can vary drastically.
I originally got into this mess with #3274, where I discovered that Boost could not be built with Python 3 because the executable is called `python3` and we were telling it to use `python`. I got deeper into this mess when I started hacking on #3140, where I discovered just how difficult it is to find the location and name of the Python libraries and headers.
Currently, half of the packages that depend on Python and need to know this information jump through hoops to determine the correct information. The other half are hard-coded to use `python`, `spec['python'].prefix.lib`, and `spec['python'].prefix.include`. Obviously, none of these packages would work for Python 3, and there's no reason to duplicate the effort. The Python package itself should contain all of the information necessary to use it properly. This is in line with the recent work by @alalazo and @davydden with respect to `spec['blas'].libs` and friends.
## Prefix
For most packages in Spack, we assume that the installation directory is `spec['python'].prefix`. This generally works for anything installed with Spack, but gets complicated when we include external packages. Python is a commonly used external package (it needs to be installed just to run Spack). If it was installed with Homebrew, `which python` would return `/usr/local/bin/python`, and most users would erroneously assume that `/usr/local` is the installation directory. If you peruse through #2173, you'll immediately see why this is not the case. Homebrew actually installs Python in `/usr/local/Cellar/python/2.7.12_2` and symlinks the executable to `/usr/local/bin/python`. `PYTHONHOME` (and presumably most things that need to know where Python is installed) needs to be set to the actual installation directory, not `/usr/local`.
Normally I would say, "sounds like user error, make sure to use the real installation directory in your `packages.yaml`". But I think we can make a special case for Python. That's what we decided in #2173 anyway. If we change our minds, I would be more than happy to simplify things.
To solve this problem, I created a `spec['python'].home` attribute that works the same way as `spec['python'].prefix` but queries Python to figure out where it was actually installed. @tgamblin Is there any way to overwrite `spec['python'].prefix`? I think it's currently immutable.
## Command
In general, Python 2 comes with both `python` and `python2` commands, while Python 3 only comes with a `python3` command. But this is up to the OS developers. For example, `/usr/bin/python` on Gentoo is actually Python 3. Worse yet, if someone is using an externally installed Python, all 3 commands may exist in the same directory! Here's what I'm thinking:
If the spec is for Python 3, try searching for the `python3` command.
If the spec is for Python 2, try searching for the `python2` command.
If neither are found, try searching for the `python` command.
## Libraries
Spack installs Python libraries in `spec['python'].prefix.lib`. Except on openSUSE 13, where it installs to `spec['python'].prefix.lib64` (see #2295 and #2253). On my CentOS 6 machine, the Python libraries are installed in `/usr/lib64`. Both need to work.
The libraries themselves change name depending on OS and Python version. For Python 2.7 on macOS, I'm seeing:
```
lib/libpython2.7.dylib
```
For Python 3.6 on CentOS 6, I'm seeing:
```
lib/libpython3.so
lib/libpython3.6m.so.1.0
lib/libpython3.6m.so -> lib/libpython3.6m.so.1.0
```
Notice the `m` after the version number. Yeah, that's a thing.
## Headers
In Python 2.7, I'm seeing:
```
include/python2.7/pyconfig.h
```
In Python 3.6, I'm seeing:
```
include/python3.6m/pyconfig.h
```
It looks like all Python 3 installations have this `m`. Tested with Python 3.2 and 3.6 on macOS and CentOS 6
Spack has really nice support for libraries (`find_libraries` and `LibraryList`), but nothing for headers. Fixed.
2017-04-30 08:24:13 +08:00
|
|
|
patterns.append(r'bin/f2py[0-9.]*$')
|
2015-02-02 22:09:35 +08:00
|
|
|
|
2015-02-17 16:21:15 +08:00
|
|
|
return match_predicate(ignore_arg, patterns)
|
2015-01-20 16:23:16 +08:00
|
|
|
|
2015-02-15 17:58:35 +08:00
|
|
|
def write_easy_install_pth(self, exts):
|
2015-02-02 22:09:35 +08:00
|
|
|
paths = []
|
2015-02-15 17:58:35 +08:00
|
|
|
for ext in sorted(exts.values()):
|
2016-06-18 02:33:09 +08:00
|
|
|
ext_site_packages = join_path(ext.prefix, self.site_packages_dir)
|
|
|
|
easy_pth = join_path(ext_site_packages, "easy-install.pth")
|
2015-02-02 22:09:35 +08:00
|
|
|
|
|
|
|
if not os.path.isfile(easy_pth):
|
|
|
|
continue
|
|
|
|
|
2017-10-23 20:23:00 +08:00
|
|
|
with open(easy_pth) as f:
|
2015-02-02 22:09:35 +08:00
|
|
|
for line in f:
|
|
|
|
line = line.rstrip()
|
|
|
|
|
|
|
|
# Skip lines matching these criteria
|
2016-06-18 02:33:09 +08:00
|
|
|
if not line:
|
|
|
|
continue
|
|
|
|
if re.search(r'^(import|#)', line):
|
|
|
|
continue
|
2016-12-08 20:35:11 +08:00
|
|
|
if (ext.name != 'py-setuptools' and
|
|
|
|
re.search(r'setuptools.*egg$', line)):
|
2016-06-18 02:33:09 +08:00
|
|
|
continue
|
2015-02-02 22:09:35 +08:00
|
|
|
|
|
|
|
paths.append(line)
|
|
|
|
|
Python command, libraries, and headers (#3367)
## Motivation
Python installations are both important and unfortunately inconsistent. Depending on the Python version, OS, and the strength of the Earth's magnetic field when it was installed, the name of the Python executable, directory containing its libraries, library names, and the directory containing its headers can vary drastically.
I originally got into this mess with #3274, where I discovered that Boost could not be built with Python 3 because the executable is called `python3` and we were telling it to use `python`. I got deeper into this mess when I started hacking on #3140, where I discovered just how difficult it is to find the location and name of the Python libraries and headers.
Currently, half of the packages that depend on Python and need to know this information jump through hoops to determine the correct information. The other half are hard-coded to use `python`, `spec['python'].prefix.lib`, and `spec['python'].prefix.include`. Obviously, none of these packages would work for Python 3, and there's no reason to duplicate the effort. The Python package itself should contain all of the information necessary to use it properly. This is in line with the recent work by @alalazo and @davydden with respect to `spec['blas'].libs` and friends.
## Prefix
For most packages in Spack, we assume that the installation directory is `spec['python'].prefix`. This generally works for anything installed with Spack, but gets complicated when we include external packages. Python is a commonly used external package (it needs to be installed just to run Spack). If it was installed with Homebrew, `which python` would return `/usr/local/bin/python`, and most users would erroneously assume that `/usr/local` is the installation directory. If you peruse through #2173, you'll immediately see why this is not the case. Homebrew actually installs Python in `/usr/local/Cellar/python/2.7.12_2` and symlinks the executable to `/usr/local/bin/python`. `PYTHONHOME` (and presumably most things that need to know where Python is installed) needs to be set to the actual installation directory, not `/usr/local`.
Normally I would say, "sounds like user error, make sure to use the real installation directory in your `packages.yaml`". But I think we can make a special case for Python. That's what we decided in #2173 anyway. If we change our minds, I would be more than happy to simplify things.
To solve this problem, I created a `spec['python'].home` attribute that works the same way as `spec['python'].prefix` but queries Python to figure out where it was actually installed. @tgamblin Is there any way to overwrite `spec['python'].prefix`? I think it's currently immutable.
## Command
In general, Python 2 comes with both `python` and `python2` commands, while Python 3 only comes with a `python3` command. But this is up to the OS developers. For example, `/usr/bin/python` on Gentoo is actually Python 3. Worse yet, if someone is using an externally installed Python, all 3 commands may exist in the same directory! Here's what I'm thinking:
If the spec is for Python 3, try searching for the `python3` command.
If the spec is for Python 2, try searching for the `python2` command.
If neither are found, try searching for the `python` command.
## Libraries
Spack installs Python libraries in `spec['python'].prefix.lib`. Except on openSUSE 13, where it installs to `spec['python'].prefix.lib64` (see #2295 and #2253). On my CentOS 6 machine, the Python libraries are installed in `/usr/lib64`. Both need to work.
The libraries themselves change name depending on OS and Python version. For Python 2.7 on macOS, I'm seeing:
```
lib/libpython2.7.dylib
```
For Python 3.6 on CentOS 6, I'm seeing:
```
lib/libpython3.so
lib/libpython3.6m.so.1.0
lib/libpython3.6m.so -> lib/libpython3.6m.so.1.0
```
Notice the `m` after the version number. Yeah, that's a thing.
## Headers
In Python 2.7, I'm seeing:
```
include/python2.7/pyconfig.h
```
In Python 3.6, I'm seeing:
```
include/python3.6m/pyconfig.h
```
It looks like all Python 3 installations have this `m`. Tested with Python 3.2 and 3.6 on macOS and CentOS 6
Spack has really nice support for libraries (`find_libraries` and `LibraryList`), but nothing for headers. Fixed.
2017-04-30 08:24:13 +08:00
|
|
|
site_packages = join_path(self.home, self.site_packages_dir)
|
2016-06-18 02:33:09 +08:00
|
|
|
main_pth = join_path(site_packages, "easy-install.pth")
|
2015-02-02 22:09:35 +08:00
|
|
|
|
|
|
|
if not paths:
|
|
|
|
if os.path.isfile(main_pth):
|
|
|
|
os.remove(main_pth)
|
|
|
|
|
|
|
|
else:
|
2017-10-23 20:23:00 +08:00
|
|
|
with open(main_pth, 'w') as f:
|
2017-03-29 00:32:50 +08:00
|
|
|
f.write("import sys; sys.__plen = len(sys.path)\n")
|
2015-02-02 22:09:35 +08:00
|
|
|
for path in paths:
|
2016-06-18 02:33:09 +08:00
|
|
|
f.write("{0}\n".format(path))
|
2017-03-29 00:32:50 +08:00
|
|
|
f.write("import sys; new=sys.path[sys.__plen:]; "
|
|
|
|
"del sys.path[sys.__plen:]; "
|
|
|
|
"p=getattr(sys,'__egginsert',0); "
|
|
|
|
"sys.path[p:p]=new; "
|
|
|
|
"sys.__egginsert = p+len(new)\n")
|
2015-02-02 22:09:35 +08:00
|
|
|
|
2015-01-20 16:23:16 +08:00
|
|
|
def activate(self, ext_pkg, **args):
|
2016-06-18 02:33:09 +08:00
|
|
|
ignore = self.python_ignore(ext_pkg, args)
|
2015-05-11 08:56:27 +08:00
|
|
|
args.update(ignore=ignore)
|
|
|
|
|
2015-01-20 16:23:16 +08:00
|
|
|
super(Python, self).activate(ext_pkg, **args)
|
|
|
|
|
2016-11-01 23:15:34 +08:00
|
|
|
exts = spack.store.layout.extension_map(self.spec)
|
2015-02-15 17:58:35 +08:00
|
|
|
exts[ext_pkg.name] = ext_pkg.spec
|
|
|
|
self.write_easy_install_pth(exts)
|
2015-02-02 22:09:35 +08:00
|
|
|
|
2015-01-20 16:23:16 +08:00
|
|
|
def deactivate(self, ext_pkg, **args):
|
2015-02-02 22:09:35 +08:00
|
|
|
args.update(ignore=self.python_ignore(ext_pkg, args))
|
2015-01-20 16:23:16 +08:00
|
|
|
super(Python, self).deactivate(ext_pkg, **args)
|
2015-02-02 22:09:35 +08:00
|
|
|
|
2016-11-01 23:15:34 +08:00
|
|
|
exts = spack.store.layout.extension_map(self.spec)
|
2016-06-18 02:33:09 +08:00
|
|
|
# Make deactivate idempotent
|
|
|
|
if ext_pkg.name in exts:
|
2015-02-17 04:41:22 +08:00
|
|
|
del exts[ext_pkg.name]
|
|
|
|
self.write_easy_install_pth(exts)
|