Details
-
Type:
Story
-
Status: Done
-
Resolution: Done
-
Fix Version/s: None
-
Component/s: Continuous Integration
-
Labels:None
-
Story Points:15
-
Epic Link:
-
Team:SQuaRE
Attachments
Issue Links
Activity
Russell Owen, graciously, tried to do a beta test install. With python 3.6 as the default interpreter, EUPS blew up during package install. My guess is this is cause by products being setup during the install, which is causing a conflict between the py2 env prepared packages and the EUPS python interp. I think the safest course of action here is to refactor newinstall.sh to bootstrap miniconda directly so build and install python envs [can optionally be] identical.
Looking on server for https://jhoblitt-curly-eups.lsst.codes/stack/osx/10.9/clang-800.0.42.1/tables/healpy-1.8.1.lsst2+5.table |
Traceback (most recent call last):
|
File "/Users/rowen/templsststack/eups/python/eups/Product.py", line 10, in <module> |
from configparser import ConfigParser |
File "/Users/rowen/templsststack/DarwinX86/python_future/0.15.2+2/lib/python/future-0.15.2-py2.7.egg/configparser/__init__.py", line 11, in <module> |
raise ImportError('This package should not be accessible on Python 3. ' |
ImportError: This package should not be accessible on Python 3. Either you are trying to run from the python-future src folder or your installation of python-future is corrupted. |
|
|
During handling of the above exception, another exception occurred:
|
|
|
Traceback (most recent call last):
|
File "/Users/rowen/templsststack/eups/bin/eups_setup", line 28, in <module> |
import eups.setupcmd |
File "/Users/rowen/templsststack/eups/python/eups/__init__.py", line 4, in <module> |
from .Product import Product |
File "/Users/rowen/templsststack/eups/python/eups/Product.py", line 12, in <module> |
from ConfigParser import ConfigParser |
ModuleNotFoundError: No module named 'ConfigParser' |
Python future 0.15.2 provides a configparser alias that exists on py2 but not on py3 installations. Py3 already has it. When EUPS loads the Python3 variant, it finds it in the Python2 installation of python-future that has been added to the PYTHONPATH. This then upsets future because Py3 is never meant to load the Py2 compatibility code. Hence the error above.
The real problem here is that the stack's PYTHONPATH contains code that is specifically installed as a Py2-only variant and exists purely to override builtins. This is probably going to be flaky. The safe thing is to control the python for everything as you are doing in DM-5126.
I also don't understand why this install is using such an old future? 0.16.0 was installed 2 months ago in DM-7110.
Per discussion on slack, the binary tarballs in the case are from v13_0, which is using future 0.15.2.
After a from scratch build of py3 packages using newinstall.sh bookstrapped miniconda, future issues have come back when installing tarballs. Oddly, this errors did not happen during the source build.
AttributeError: module 'eups' has no attribute 'utils' |
Traceback (most recent call last):
|
File "/Users/square/jhoblitt/test/eups/python/eups/distrib/server.py", line 14, in <module> |
from urllib2 import urlopen, HTTPError, URLError |
ImportError: No module named 'urllib2' |
|
|
During handling of the above exception, another exception occurred:
|
|
|
Traceback (most recent call last):
|
File "/Users/square/jhoblitt/test/eups/bin/eups", line 12, in <module> |
import eups.cmd |
File "/Users/square/jhoblitt/test/eups/python/eups/__init__.py", line 6, in <module> |
from .cmd import commandCallbacks |
File "/Users/square/jhoblitt/test/eups/python/eups/cmd.py", line 44, in <module> |
from . import distrib |
File "/Users/square/jhoblitt/test/eups/python/eups/distrib/__init__.py", line 31, in <module> |
from .Repositories import Repositories |
File "/Users/square/jhoblitt/test/eups/python/eups/distrib/Repositories.py", line 12, in <module> |
from . import server |
File "/Users/square/jhoblitt/test/eups/python/eups/distrib/server.py", line 16, in <module> |
from urllib.request import urlopen |
File "/Users/square/jhoblitt/test/miniconda3-4.2.12/lib/python3.5/urllib/request.py", line 88, in <module> |
import http.client |
File "/Users/square/jhoblitt/test/DarwinX86/python_future/0.16.0/lib/python/future-0.16.0-py2.7.egg/http/__init__.py", line 7, in <module> |
raise ImportError('This package should not be accessible on Python 3. ' |
ImportError: This package should not be accessible on Python 3. Either you are trying to run from the python-future src folder or your installation of python-future is corrupted. |
|
The future-0.16.0-py2.7.egg path component is very suspicious.
Yes. That's the same issue from previously in a different form. A python3 interpreter is importing a python2 future. Looks suspiciously like py3 binaries are installing py2 tarballs.
My guess is that this was the result of a py3 rebuild having gotten tarballs from a mix of py2 and py3 EUPS_PKGROOTs on separate runs. I'm doing a from scratch py3 build to see if the py2 egg appears.
The task of adding the tarball build into the weekly release job is small and has been merged. This ticket is to be left open until next week after the automatic weekly release process has run to debug any issues that come up.