py36-graph-tool uses incorrect python version 2.7

[ssllmit (ss)]

py36-graph-tool uses the incorrect python version, default to v. 2.7 in its port file, which results in incorrect dependencies during the build.

First, clean everything and set python to use v. 3.6:

sudo port clean --all py36-graph-tool, 
sudo port select --set python python36
hash -r

Confirm:

$ python --version
Python 3.6.7

An install of py36-graph-tool gets the wrong python version (default v. 2.7):

sudo port -pN install py36-graph-tool
--->  Computing dependencies for py36-graph-tool
--->  Dependencies to be installed: boost cgal
--->  Fetching archive for boost
--->  Attempting to fetch boost-1.66.0_3+no_single+no_static+python27.darwin_17.x86_64.tbz2 from https://packages.macports.org/boost

This issue appears to go beyond py36-graph-tool because boost also shows the same dependency issue:

port list depof:boost
bzip2                          @1.0.6          archivers/bzip2
expat                          @2.2.6          textproc/expat
icu                            @58.2           devel/icu
libiconv                       @1.15           textproc/libiconv
python27                       @2.7.15         lang/python27
zlib                           @1.2.11         archivers/zlib

I confirm this issue on a separate system with a newly installed Macports, and do not believe this is a local configuration issue.

FWIW, I'm trying to track down a segmentation fault with gt.graph_draw that I hope is related to this build problem…

gt.graph_draw(g)
Segmentation fault: 11

[mf2k (Frank Schima)]

What happens when you install boost +python36?

[jmroot (Joshua Root)]

You seem to have a couple of misconceptions. First: port select --set python python36 does one thing only: it installs a python link that points to python3.6. It does not affect the dependencies of any port.

Second: boost sets its own dependencies, they are not chosen by py-graph-tool. It happens that boost defaults to +python27.

There's no evidence here that py36-graph-tool is itself using the wrong python version.

[jmroot (Joshua Root)]

I'll leave closing this to the relevant maintainers just because there may possibly be a conversation to be had about boost's default variants.

[ryandesign (Ryan Carsten Schmidt)]

It could make sense to update boost's default python variant to the latest version of python 3 at this point. That change would have to be coordinated with a zillion ports that use boost. As Josh said it has nothing to do with py36-graph-tool however.

[mf2k (Frank Schima)]

I normally have my preferred python added as a default variant in my variants.conf file to keep all of my ports synced on the same python version. However, I think I had to remove it one time because of problems building boost with python36. So I think changing boost to default to python36, or better yet python37, makes sense so that we know it works.

[ssllmit (ss)]

I tried the suggestion of adding +python37 to /opt/local/etc/macports/variants.conf, but this causes breakage of many ports.

I encountered this issue while doing automated migration of a Macports setup (wiki:Migration), and while doing an automated update to python37:

sudo port -pN install python37 `port -qv installed | egrep -e '^\s*py36' | perl -ane 'chomp; $_ = $F[0]; s/py36/py37/; print $_, " ";'`

With the current port file settings, this process will break because ports like boost aren't installed with the correct python version.

[ryandesign (Ryan Carsten Schmidt)]

Replying to ssllmit:

I tried the suggestion of adding +python37 to /opt/local/etc/macports/variants.conf, but this causes breakage of many ports.

It should work. Without further information from you about the nature of this breakage, we can't do anything to fix it.

[michaelld (Michael Dickens)]

Does this MP commit fix this issue? [fb0c6b307699fa7c41f412937c4767b2a21445a0/macports-ports]