-
Notifications
You must be signed in to change notification settings - Fork 713
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
{vis}[foss/2016a] PyBERT 1.7.9 w/Python-3.5.1 (WIP) #3446
Conversation
toolchain = {'name': 'foss', 'version': '2016a'} | ||
|
||
source_urls = ['https://github.com/enthought/chaco/archive/'] | ||
sources = ['%s.tar.gz' % commit_id] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@hajgato 4.5.0 is the latest official release, why not use that?
Once we start diverging from official releases, we'll need to stick to it forever, since 20160817
will always be newer than 4.5.0
or any other newer version...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@boegel I had two options. Try to do everything with Python3
, as the user want to use PyBERT
simultaneously with pyGIMLi
. As far as I got from pyGIMLi
homepage, its requires Python3
. So I had to use Python3
here as well. and the latest official release is not yet Python3
compatible. I could use version4.6.0beta.20160817
(or whatever is the version claimed by the code).
Other possibility to make a Python2/2.7.11-Python-3.5.1
, and use all the stuff here with that.
(chaco/4.5.0-foss-2016a-Python-2.7.11-Python-3.5.1
or so). The option to use system Python
is not a good way, since PyBERT
requires Python 2.7
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
according to http://www.pygimli.org/installation.html#optional-prerequisites, pyGIMLi is compatible with Python 2.7 as well?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
also, I'm not sure what Python2/2.7.11-Python-3.5.1
is? is that Python 2 and 3 combined? that's a nice recipe for disaster ;)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, for the future what is the recipe to use python2 and python3 together. Ok, in this project it is not needed, but if in the future this problem will pop up? If I have a linux distro, I can have both, and most of the cases its not a disaster.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the right approach would be to make a Python2/2.7.11-*
module, and load Python (3) and Python2 together as deps
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How do you prevent users to load python (2) and python2 module together? I think that's also a recipe for disaster (for example which order did they loaded it)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nothing would break then, one module would just shadow the other?
@boegel I can confirm that PyBERT does not work (prblem with the matplotlib interface) |
@boegel: Ok, I found the error, it needs an old version of |
@boegel: I put this back as |
Python2 version will be made. |
No description provided.