Opened 5 years ago
Closed 2 years ago
#59303 closed enhancement (fixed)
scons: switch to python3x
Reported by: | llamafilm | Owned by: | ryandesign (Ryan Carsten Schmidt) |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | 2.6.1 |
Keywords: | Cc: | ||
Port: | scons |
Description
Scons wants to install python27 even though I already have python37. It should run fine with Python 3.5 or higher according to the project description:
Running SCons requires either Python version 2.7 or Python 3.5 or higher. There should be no other dependencies or requirements to run SCons.
$ port deps scons Full Name: scons @3.1.1_0 Library Dependencies: python27
Change History (8)
comment:1 Changed 5 years ago by ryandesign (Ryan Carsten Schmidt)
Owner: | set to ryandesign |
---|---|
Status: | new → assigned |
Summary: | Scons should not require python2 → scons: switch to python3x |
Type: | defect → enhancement |
comment:2 Changed 5 years ago by llamafilm
I understand not wanting to force the change. But is there no way to list multiple python versions as a dependency?
comment:3 Changed 4 years ago by mf2k (Frank Schima)
Can this please be revisited? According to the current README, Scons 3 requires python >= 3.5. So switching should not be a problem. Please consider using python 3.8.
comment:4 follow-up: 5 Changed 4 years ago by mf2k (Frank Schima)
For reference, Scons in homebrew uses python 3.8.
comment:5 Changed 4 years ago by ryandesign (Ryan Carsten Schmidt)
Replying to mf2k:
Can this please be revisited? According to the current README, Scons 3 requires python >= 3.5. So switching should not be a problem. Please consider using python 3.8.
"scons [3.1.2] requires either Python 2.7 or Python 3.5 or higher" (manpage)
Replying to mf2k:
For reference, Scons in homebrew uses python 3.8.
I guess they've done the necessary work of patching all their packages that use scons to be compatible with python 3. I don't think we have yet. Some work has been done in https://github.com/macports/macports-ports/pull/6104 but I don't think it was completed.
comment:6 Changed 3 years ago by bdbaddog
Would it be reasonable to have a scons 3.1.2 as port named "scons27" which then all existing ports which won't build with python3 or more modern SCons can use?
Seems like otherwise the burden of updating all (and in some case unmaintained) packages to build with python 3 and newer scons will remain a huge undertaking?
(I'm the SCons maintainer)
comment:7 Changed 3 years ago by kencu (Ken)
Sure, sounds just fine if there is a use case for it, as you point out there is.
comment:8 Changed 2 years ago by ryandesign (Ryan Carsten Schmidt)
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
It is reasonable to investigate switching the scons port to use python37. However, I am concerned that doing so might cause problems for some of the ports that use scons. They might use python2-specific features in their SConscript files and might break if we switch to python3. (Arguably, those would be bugs in those other ports, which should be fixed.) Or they might use other python modules in their SConscript files; if they do, the port would declare dependencies on the python27 versions of those modules, and if we change the python version that scons uses, we would have to identify all those ports and update their dependencies to use the new python version. So while it could be done, it should be done carefully.
One concern that occurs to me is mongodb, which is a large software package that uses scons as its build system. At least in version 4.0.x, its build scripts specifically test for python 2.7 and exit with an error if any other version is used. I have not checked mongodb 4.2.0, and I have not tested whether using python3 would break this build, but I would not want to make a change to the scons port that would break mongodb, or other ports. As far as I know, at present, everything is working fine with python27, and while I understand that support for python27 will end soon and ideally we should move to a newer version, I am more interested in not breaking things.
I am the maintainer of the scons port so I will assign the ticket to myself but I am unprepared to invest the necessary time in doing any of this work or investigation at this time. If others wish to do so and submit a pull request of a working tested solution, that's fine.