Check the main.log - the destroot stage clearly is still (for some bizarre reason) executing those commands. I don't know if you need to do anything after modifying a Portfile to make the changes take effect. Looking at my command history, it doesn't look like I did.

Your Portfile is different than mine, by the way - I don't have the plain post-destroot{} line. Maybe selfupdate, and then modify the Portfile again?

Thanks I thought that was pretty strange. I tried selfupdating but nothing changed (I had also done so before modifying the portfile). Besides, would you mind attaching your modified Portfile and maybe where it is located in your file system? So I can test it as well. Thank you

Check the main.log - the destroot stage clearly is still (for some bizarre reason) executing those commands. I don't know if you need to do anything after modifying a Portfile to make the changes take effect. Looking at my command history, it doesn't look like I did.

Your Portfile is different than mine, by the way - I don't have the plain post-destroot{} line. Maybe selfupdate, and then modify the Portfile again?

Thanks I thought that was pretty strange. I tried selfupdating but nothing changed (I had also done so before modifying the portfile). Besides, would you mind attaching your modified Portfile and maybe where it is located in your file system? So I can test it as well. Thank you

Check the main.log - the destroot stage clearly is still (for some bizarre reason) executing those commands. I don't know if you need to do anything after modifying a Portfile to make the changes take effect. Looking at my command history, it doesn't look like I did.

Your Portfile is different than mine, by the way - I don't have the plain post-destroot{} line. Maybe selfupdate, and then modify the Portfile again?

Thanks I thought that was pretty strange. I tried selfupdating but nothing changed (I had also done so before modifying the portfile). Besides, would you mind attaching your modified Portfile and maybe where it is located in your file system? So I can test it as well. Thank you

Check the main.log - the destroot stage clearly is still (for some bizarre reason) executing those commands. I don't know if you need to do anything after modifying a Portfile to make the changes take effect. Looking at my command history, it doesn't look like I did.

Your Portfile is different than mine, by the way - I don't have the plain post-destroot{} line. Maybe selfupdate, and then modify the Portfile again?

Of course, the most annoying bug of all in pymol is how utterly useless the "require_active_variants" field is.
From a clean install of MacPorts on Yosemite, with the first install being "sudo port -d install pymol", port
totally ignores the lines...

So apply the ugly hack below will purge it until we discover why port is misbehaving.

The reason for the destroot failure is a change that was made to the python 1.0 portgroup in r126798. That this change caused a destroot failure in pymol does not indicate a regression of the python 1.0 portgroup, but rather that pymol is not using a directive it should be using to disable this particular functionality of the python 1.0 portgroup. Pymol should probably have been using this directive all along, it just didn't result in a destroot failure until this change.

Ports using the python 1.0 portgroup install their files into deep directories within ${frameworks_dir}/Python.framework. This is inconvenient for users who want to run programs that those ports install. For this reason, when using python 2.6 or later, the python 1.0 portgroup by default creates symlinks to those programs and places them in ${prefix}/bin. Ports that do not want this behavior can set "python.link_binaries no".

Python module ports—those whose names begin with "py-", which install python modules that other programs written in python will use—usually have subports for multiple versions of python each, for example for 2.7 and 3.4. We want the user to be able to install these simultaneously, which would not be possible if they each installed the same files in the same locations. For this reason, when using python 2.6 or later, the python 1.0 portgroup by default appends a versioned suffix to the name of each symlink. Ports that do not want this behavior can set "python.link_binaries_suffix" to a different value, including the empty string if no suffix is desired.

Python application ports—those whose names do not begin with "py-", which install programs the user is expected to use directly, and which do not install modules usable by other python software—do not have subports and are only available for a specific version of python. Python application ports were previously expected to manually set "python.link_binaries_suffix" to the empty string. r126798 changes the python 1.0 portgroup to make that happen automatically.

Pymol is unusual in that it installs a wrapper script that users are expected to run. But the pymol port does not modify the default values of python.link_binaries or python.link_binaries_suffix. So prior to this change, an unwanted and unneeded symlink ${prefix}/bin/pymol-2.7 was being created which users were expected to ignore, and in addition the port was installing its own wrapper script at ${prefix}/bin/pymol which users were expected to use. After this change, the unwanted and unneeded symlink is being installed at ${prefix}/bin/pymol, thus preventing the pymol wrapper script from being installed there.

If the wrapper script is needed, then the solution is to instruct the python 1.0 portgroup to not create the symlink, by setting "python.link_binaries no". I have committed this change in r129465 because it matches the behavior of Jack's patch in comment:13 and #45721.

If the wrapper script is not needed, then the solution is to remove the wrapper script. Jack suggested this in #46218 so we can explore that option more there.

So apply the ugly hack below will purge it until we discover why port is misbehaving.

The reason for the destroot failure is a change that was made to the python 1.0 portgroup in r126798. That this change caused a destroot failure in pymol does not indicate a regression of the python 1.0 portgroup, but rather that pymol is not using a directive it should be using to disable this particular functionality of the python 1.0 portgroup. Pymol should probably have been using this directive all along, it just didn't result in a destroot failure until this change.

Ports using the python 1.0 portgroup install their files into deep directories within ${frameworks_dir}/Python.framework. This is inconvenient for users who want to run programs that those ports install. For this reason, when using python 2.6 or later, the python 1.0 portgroup by default creates symlinks to those programs and places them in ${prefix}/bin. Ports that do not want this behavior can set "python.link_binaries no".

Python module ports—those whose names begin with "py-", which install python modules that other programs written in python will use—usually have subports for multiple versions of python each, for example for 2.7 and 3.4. We want the user to be able to install these simultaneously, which would not be possible if they each installed the same files in the same locations. For this reason, when using python 2.6 or later, the python 1.0 portgroup by default appends a versioned suffix to the name of each symlink. Ports that do not want this behavior can set "python.link_binaries_suffix" to a different value, including the empty string if no suffix is desired.

Python application ports—those whose names do not begin with "py-", which install programs the user is expected to use directly, and which do not install modules usable by other python software—do not have subports and are only available for a specific version of python. Python application ports were previously expected to manually set "python.link_binaries_suffix" to the empty string. r126798 changes the python 1.0 portgroup to make that happen automatically.

Pymol is unusual in that it installs a wrapper script that users are expected to run. But the pymol port does not modify the default values of python.link_binaries or python.link_binaries_suffix. So prior to this change, an unwanted and unneeded symlink ${prefix}/bin/pymol-2.7 was being created which users were expected to ignore, and in addition the port was installing its own wrapper script at ${prefix}/bin/pymol which users were expected to use. After this change, the unwanted and unneeded symlink is being installed at ${prefix}/bin/pymol, thus preventing the pymol wrapper script from being installed there.

If the wrapper script is needed, then the solution is to instruct the python 1.0 portgroup to not create the symlink, by setting "python.link_binaries no". I have committed this change in r129465 because it matches the behavior of Jack's patch in comment:13 and #45721.

If the wrapper script is not needed, then the solution is to remove the wrapper script. Jack suggested this in #46218 so we can explore that option more there.