import python 3.7
Hey,
I'd like to have python 3.7 for 6.4 (not as the default version of
course) and somewhere during 6.4 cycle we could switch over to it for
our python ports.
I took 3.6 and adapted it for the new version.
Does the test suite work for you? In my case it seems it never ends with
"running: test_asyncio (2 min 52 sec)" until I ^c. If people have the
same, I'll add TEST_IS_INTERACTIVE=Yes
Attached, the diff for our current files and the tgz for the 3.7
directory.
Comments? OK?
Cheers,
Daniel
? 3.7
Index: Makefile
===
RCS file: /cvs/ports/lang/python/Makefile,v
retrieving revision 1.68
diff -u -p -r1.68 Makefile
--- Makefile 8 Jul 2017 08:28:00 - 1.68
+++ Makefile 8 Sep 2018 18:20:36 -
@@ -3,6 +3,7 @@
SUBDIR =
SUBDIR += 2.7
SUBDIR += 3.6
+SUBDIR += 3.7
.include
Index: Makefile.inc
===
RCS file: /cvs/ports/lang/python/Makefile.inc,v
retrieving revision 1.124
diff -u -p -r1.124 Makefile.inc
--- Makefile.inc 3 Nov 2017 13:13:05 - 1.124
+++ Makefile.inc 8 Sep 2018 18:20:36 -
@@ -126,7 +126,7 @@ FAKE_FLAGS += RANLIB=:
# and QtWebKit require W|X mappings.
USE_WXNEEDED = Yes
-.if ${VERSION} == "3.6"
+.if ${VERSION} == "3.6" || ${VERSION} == "3.7"
ALL_TARGET = all
.else
ALL_TARGET = all ./Lib/plat-openbsd6
Index: python.port.mk
===
RCS file: /cvs/ports/lang/python/python.port.mk,v
retrieving revision 1.99
diff -u -p -r1.99 python.port.mk
--- python.port.mk 24 Jul 2018 12:10:10 - 1.99
+++ python.port.mk 8 Sep 2018 18:20:36 -
@@ -24,7 +24,8 @@ MODPY_VERSION ?= ${MODPY_DEFAULT_VERSION
# verify if MODPY_VERSION forced is correct
.else
. if ${MODPY_VERSION} != "2.7" && \
- ${MODPY_VERSION} != "3.6"
+ ${MODPY_VERSION} != "3.6" && \
+ ${MODPY_VERSION} != "3.7"
ERRORS += "Fatal: unknown or unsupported MODPY_VERSION: ${MODPY_VERSION}"
. endif
.endif
3.7.tgz
Description: application/compressed-tar
Import python 3.7
Daniel your update builds and runs fine for me on amd64. Two notes though: Current version is now 3.7.1, I tested and same patches apply to this version. Second is if we have side by side installs then /usr/local/bin/python3 should be a symlink to the users preferred version. Not owned by a package, same for pip. We can likely solve this by a post install message for the user. Thank you for the work on this.
Re: import python 3.7
On Sat, Sep 08, 2018 at 02:28:06PM -0400, Daniel Jakots wrote: > Hey, > > I'd like to have python 3.7 for 6.4 (not as the default version of > course) and somewhere during 6.4 cycle we could switch over to it for > our python ports. > > I took 3.6 and adapted it for the new version. > > Does the test suite work for you? In my case it seems it never ends with > "running: test_asyncio (2 min 52 sec)" until I ^c. If people have the > same, I'll add TEST_IS_INTERACTIVE=Yes Hmm. Why not try and fix it? :-) -- Antoine
Re: import python 3.7
On Sat, 8 Sep 2018 14:28:06 -0400, Daniel Jakots wrote: > Does the test suite work for you? In my case it seems it never ends > with "running: test_asyncio (2 min 52 sec)" until I ^c. If people > have the same, I'll add TEST_IS_INTERACTIVE=Yes I looked into it and didn't find any solution. It happens on cpython HEAD as well so I added it. > Attached, the diff for our current files and the tgz for the 3.7 > directory. New tgz attached because the plist needed some @comment. fwiw, tested on arm64, it packages fine and tests result looks the same Cheers, Daniel 3.7.tgz Description: application/compressed-tar
Re: import python 3.7
On Tue, 11 Sep 2018 22:19:13 -0400, Daniel Jakots wrote: > New tgz attached because the plist needed some @comment. ping
Re: import python 3.7
On Tue, 11 Sep 2018 22:19:13 -0400, Daniel Jakots
wrote:
> On Sat, 8 Sep 2018 14:28:06 -0400, Daniel Jakots
> wrote:
>
> > Does the test suite work for you? In my case it seems it never ends
> > with "running: test_asyncio (2 min 52 sec)" until I ^c. If people
> > have the same, I'll add TEST_IS_INTERACTIVE=Yes
>
> I looked into it and didn't find any solution. It happens on cpython
> HEAD as well so I added it.
>
> > Attached, the diff for our current files and the tgz for the 3.7
> > directory.
>
> New tgz attached because the plist needed some @comment.
New tgz because the PLIST-main listed items it shouldn't (spotted by
Rafael, thanks!)
Cheers,
Daniel
3.7.tgz
Description: application/compressed-tar
? 3.7
? 3.7.tgz
Index: Makefile
===
RCS file: /cvs/ports/lang/python/Makefile,v
retrieving revision 1.68
diff -u -p -r1.68 Makefile
--- Makefile 8 Jul 2017 08:28:00 - 1.68
+++ Makefile 18 Sep 2018 21:29:54 -
@@ -3,6 +3,7 @@
SUBDIR =
SUBDIR += 2.7
SUBDIR += 3.6
+SUBDIR += 3.7
.include
Index: Makefile.inc
===
RCS file: /cvs/ports/lang/python/Makefile.inc,v
retrieving revision 1.125
diff -u -p -r1.125 Makefile.inc
--- Makefile.inc 18 Sep 2018 16:43:12 - 1.125
+++ Makefile.inc 18 Sep 2018 21:29:54 -
@@ -125,7 +125,7 @@ FAKE_FLAGS += RANLIB=:
# and QtWebKit require W|X mappings.
USE_WXNEEDED = Yes
-.if ${VERSION} == "3.6"
+.if ${VERSION} == "3.6" || ${VERSION} == "3.7"
ALL_TARGET = all
.else
ALL_TARGET = all ./Lib/plat-openbsd6
Index: python.port.mk
===
RCS file: /cvs/ports/lang/python/python.port.mk,v
retrieving revision 1.99
diff -u -p -r1.99 python.port.mk
--- python.port.mk 24 Jul 2018 12:10:10 - 1.99
+++ python.port.mk 18 Sep 2018 21:29:54 -
@@ -24,7 +24,8 @@ MODPY_VERSION ?= ${MODPY_DEFAULT_VERSION
# verify if MODPY_VERSION forced is correct
.else
. if ${MODPY_VERSION} != "2.7" && \
- ${MODPY_VERSION} != "3.6"
+ ${MODPY_VERSION} != "3.6" && \
+ ${MODPY_VERSION} != "3.7"
ERRORS += "Fatal: unknown or unsupported MODPY_VERSION: ${MODPY_VERSION}"
. endif
.endif
Re: import python 3.7
On Tue, 18 Sep 2018 20:21:01 -0400, Daniel Jakots wrote: > On Tue, 11 Sep 2018 22:19:13 -0400, Daniel Jakots > wrote: > > > On Sat, 8 Sep 2018 14:28:06 -0400, Daniel Jakots > > wrote: > > > > > Does the test suite work for you? In my case it seems it never > > > ends with "running: test_asyncio (2 min 52 sec)" until I ^c. If > > > people have the same, I'll add TEST_IS_INTERACTIVE=Yes > > > > I looked into it and didn't find any solution. It happens on cpython > > HEAD as well so I added it. > > > > > Attached, the diff for our current files and the tgz for the 3.7 > > > directory. > > > > New tgz attached because the plist needed some @comment. > > New tgz because the PLIST-main listed items it shouldn't (spotted by > Rafael, thanks!) ping
Re: import python 3.7
On Thu Sep 27, 2018 at 07:35:50AM -0400, Daniel Jakots wrote: > On Tue, 18 Sep 2018 20:21:01 -0400, Daniel Jakots > wrote: > > > On Tue, 11 Sep 2018 22:19:13 -0400, Daniel Jakots > > wrote: > > > > > On Sat, 8 Sep 2018 14:28:06 -0400, Daniel Jakots > > > wrote: > > > > > > > Does the test suite work for you? In my case it seems it never > > > > ends with "running: test_asyncio (2 min 52 sec)" until I ^c. If > > > > people have the same, I'll add TEST_IS_INTERACTIVE=Yes > > > > > > I looked into it and didn't find any solution. It happens on cpython > > > HEAD as well so I added it. > > > > > > > Attached, the diff for our current files and the tgz for the 3.7 > > > > directory. > > > > > > New tgz attached because the plist needed some @comment. > > > > New tgz because the PLIST-main listed items it shouldn't (spotted by > > Rafael, thanks!) > > ping > I see no impact and no risks if there are no objections. ok rsadowski@
Re: Import python 3.7
On 2018/11/15 09:58, Edward Lopez-Acosta wrote: > Daniel your update builds and runs fine for me on amd64. > > Two notes though: > > Current version is now 3.7.1, I tested and same patches apply to this > version. > > Second is if we have side by side installs then /usr/local/bin/python3 > should be a symlink to the users preferred version. Not owned by a package, > same for pip. We can likely solve this by a post install message for the > user. With the current setup some scripts rely on "#!/usr/bin/env python3" working and in that case /usr/local/bin/python3 *has* to be owned by the package, otherwise dependencies on python libraries get messed up. Unless there's a *very* good reason not to I'd recommend replacing 3.6 with 3.7 rather than having the two in parallel.
Re: Import python 3.7
I am in agreement with the replacement. The symlink was a suggestion if for some reason people want to have both available. On Thursday, November 15, 2018, Stuart Henderson wrote: > On 2018/11/15 09:58, Edward Lopez-Acosta wrote: >> Daniel your update builds and runs fine for me on amd64. >> >> Two notes though: >> >> Current version is now 3.7.1, I tested and same patches apply to this >> version. >> >> Second is if we have side by side installs then /usr/local/bin/python3 >> should be a symlink to the users preferred version. Not owned by a package, >> same for pip. We can likely solve this by a post install message for the >> user. > > With the current setup some scripts rely on "#!/usr/bin/env python3" working > and in that case /usr/local/bin/python3 *has* to be owned by the package, > otherwise dependencies on python libraries get messed up. > > Unless there's a *very* good reason not to I'd recommend replacing 3.6 with > 3.7 rather than having the two in parallel. > >
Re: Import python 3.7
Stuart, I did some thinking on this as a heavy consumer, and light developer, of Python applications. There are 455 Python3 modules currently in the repository would would be unreasonable to test all of them [1]. That being said there also appears to be hesitation on importing updated modules by the OpenBSD team [2]. Given that a large percentage of these are probably out of date they may not work with Python 3.7. I anticipate a large number of issues when making 3.7 the default, unless modules catch up due to changes with Py3.7. That being said I do still support that decision and think it would be a good step forward for the ports tree. Thoughts on how this can happen? I have tested Daniel's update to 3.7 and it seems fine for me during my normal usage and the modules I use. Thank you, Edward Lopez-Acosta [1] $ pkg_info -Q py3- | grep -E "^py3-" -c 455 [2] https://marc.info/?l=openbsd-ports&m=154250379325554&w=2 https://marc.info/?l=openbsd-ports&m=154232569512562&w=2 https://marc.info/?l=openbsd-ports&m=154241864207006&w=2 https://marc.info/?l=openbsd-ports&m=154241778006783&w=2 https://marc.info/?l=openbsd-ports&m=154232597012625&w=2 https://marc.info/?l=openbsd-ports&m=154247815319002&w=2 https://marc.info/?l=openbsd-ports&m=154250517226370&w=2 https://marc.info/?l=openbsd-ports&m=154269346520288&w=2 https://marc.info/?l=openbsd-ports&m=153990734713078&w=2 https://marc.info/?l=openbsd-ports&m=153713104304464&w=2 On 11/15/18 10:19 AM, Stuart Henderson wrote: On 2018/11/15 09:58, Edward Lopez-Acosta wrote: Daniel your update builds and runs fine for me on amd64. Two notes though: Current version is now 3.7.1, I tested and same patches apply to this version. Second is if we have side by side installs then /usr/local/bin/python3 should be a symlink to the users preferred version. Not owned by a package, same for pip. We can likely solve this by a post install message for the user. With the current setup some scripts rely on "#!/usr/bin/env python3" working and in that case /usr/local/bin/python3 *has* to be owned by the package, otherwise dependencies on python libraries get messed up. Unless there's a *very* good reason not to I'd recommend replacing 3.6 with 3.7 rather than having the two in parallel.
Re: Import python 3.7
On 2018/11/20 17:11, Edward Lopez-Acosta wrote: > Stuart, > > I did some thinking on this as a heavy consumer, and light developer, of > Python applications. > > There are 455 Python3 modules currently in the repository would would be > unreasonable to test all of them [1]. Yes it would be unreasonable to do runtime testing on all of them. But they are going to need REVISION bumped on the whole lot of them for a python version switch and at least build testing is needed to make sure we don't break the ports tree. > That being said there also appears to > be hesitation on importing updated modules by the OpenBSD team [2]. You send diffs for a stack of updates in one go, are missing finding dependencies in some cases, and are giving the impression of working fast (which is not *necessarily* a problem but might be - we don't really know you / your work and whether it's fast+careful or just fast). So yes there is hesitation to just pushing these to the tree without further thought and tests.
Re: Import python 3.7
I generally work fast and careful, and the docs are lacking on how to find dependencies (unless I am missing it). As noted previously though there are a large number of things outdated, so of course submissions will be in batches, not sure how you expect this worked around. If there is a module I use, or am just working to update in the tree, and the dependencies are outdated I will send those at the same time as its required. I was not requesting they immediately be pushed to the tree without review but there is also a lack of feedback for me to know what changes are needed to improve my porting and make it easier for you guys going forward. Edward Lopez-Acosta On 11/20/18 5:39 PM, Stuart Henderson wrote: On 2018/11/20 17:11, Edward Lopez-Acosta wrote: Stuart, I did some thinking on this as a heavy consumer, and light developer, of Python applications. There are 455 Python3 modules currently in the repository would would be unreasonable to test all of them [1]. Yes it would be unreasonable to do runtime testing on all of them. But they are going to need REVISION bumped on the whole lot of them for a python version switch and at least build testing is needed to make sure we don't break the ports tree. That being said there also appears to be hesitation on importing updated modules by the OpenBSD team [2]. You send diffs for a stack of updates in one go, are missing finding dependencies in some cases, and are giving the impression of working fast (which is not *necessarily* a problem but might be - we don't really know you / your work and whether it's fast+careful or just fast). So yes there is hesitation to just pushing these to the tree without further thought and tests.
