Thread: [SQLObject] Python 3, FormEncode, Travis, Tox
SQLObject is a Python ORM.
Brought to you by:
ianbicking,
phd
Menu
▾
▴
sqlobject-discuss
|
From: Oleg B. <ph...@ph...> - 2016-07-25 10:39:57
|
Does anybody here use SQLObject with Python 3? I started to believe it's
still impossible due to FormEncode not being ready for Python 3.4. But
our tests at Travis are passing. So I thing there is something wrong
significantly with the tests. Either Travis or Tox are betraying us.
Oleg.
--
Oleg Broytman http://phdru.name/ ph...@ph...
Programmers don't die, they just GOSUB without RETURN.
|
|
From: Neil M. <drn...@gm...> - 2016-07-25 11:03:41
|
On 25 July 2016 at 12:40, Oleg Broytman <ph...@ph...> wrote: > Does anybody here use SQLObject with Python 3? I started to believe it's > still impossible due to FormEncode not being ready for Python 3.4. But > our tests at Travis are passing. So I thing there is something wrong > significantly with the tests. Either Travis or Tox are betraying us. As far as I'm aware, no-one has reported significant issues with formencode 1.3.0 and python 3.4 . Formencode passes it's own test suite on python 3.4, and has for quite some time. https://travis-ci.org/formencode/formencode For the record, I am succesfully running a couple of programs using SQLObject 3 and python 3.4. The python3 Debian package build for sqlobject also runs the test suite, so it's not just passing the tests in the travis environment https://buildd.debian.org/status/fetch.php?pkg=sqlobject&arch=all&ver=3.0.0%2Bdfsg-2&stamp=1469130355 (although that's only with python 3.5) -- Neil Muller drn...@gm... I've got a gmail account. Why haven't I become cool? |
|
From: Oleg B. <ph...@ph...> - 2016-07-25 11:17:24
|
Hi! On Mon, Jul 25, 2016 at 01:03:33PM +0200, Neil Muller <drn...@gm...> wrote: > On 25 July 2016 at 12:40, Oleg Broytman <ph...@ph...> wrote: > > Does anybody here use SQLObject with Python 3? I started to believe it's > > still impossible due to FormEncode not being ready for Python 3.4. But > > our tests at Travis are passing. So I thing there is something wrong > > significantly with the tests. Either Travis or Tox are betraying us. > > As far as I'm aware, no-one has reported significant issues with formencode > 1.3.0 and python 3.4 . > Formencode passes it's own test suite on python 3.4, and has for quite some > time. > https://travis-ci.org/formencode/formencode > > For the record, I am succesfully running a couple of programs using > SQLObject 3 and python 3.4. > > The python3 Debian package build for sqlobject also runs the test suite, so > it's not just passing the tests in the travis environment > https://buildd.debian.org/status/fetch.php?pkg=sqlobject&arch=all&ver=3.0.0%2Bdfsg-2&stamp=1469130355 > (although > that's only with python 3.5) Thank you! Than there is something wrong with me: $ mkvirtualenv -p python3.4 SQLObject-py3 Running virtualenv with interpreter /usr/bin/python3.4 $ pip3 install SQLObject Collecting SQLObject Using cached SQLObject-3.0.0-py2.py3-none-any.whl Collecting PyDispatcher>=2.0.4 (from SQLObject) Collecting FormEncode>=1.1.1 (from SQLObject) Installing collected packages: PyDispatcher, FormEncode, SQLObject Successfully installed FormEncode-1.3.0 PyDispatcher-2.0.5 SQLObject-3.0.0 $ python3.4 -c "from sqlobject import col" Traceback (most recent call last): File "<string>", line 1, in <module> File "/home/phd/.virtualenvs/SQLObject-py3/lib/python3.4/site-packages/sqlobject/__init__.py", line 8, in <module> from .col import * # noqa File "/home/phd/.virtualenvs/SQLObject-py3/lib/python3.4/site-packages/sqlobject/col.py", line 31, in <module> from formencode import compound, validators File "/home/phd/.virtualenvs/SQLObject-py3/lib/python3.4/site-packages/formencode/__init__.py", line 3, in <module> from formencode.api import ( File "/home/phd/.virtualenvs/SQLObject-py3/lib/python3.4/site-packages/formencode/api.py", line 109, in <module> class Invalid(Exception): File "/home/phd/.virtualenvs/SQLObject-py3/lib/python3.4/site-packages/formencode/api.py", line 153, in Invalid if unicode is not str: # Python 2 NameError: name 'unicode' is not defined $ python3.4 Python 3.4.2 (default, Oct 8 2014, 13:14:40) [GCC 4.9.1] on linux Type "help", "copyright", "credits" or "license" for more information. >>> unicode Traceback (most recent call last): File "<stdin>", line 1, in <module> NameError: name 'unicode' is not defined > -- > Neil Muller > drn...@gm... > > I've got a gmail account. Why haven't I become cool? Oleg. -- Oleg Broytman http://phdru.name/ ph...@ph... Programmers don't die, they just GOSUB without RETURN. |
|
From: Neil M. <drn...@gm...> - 2016-07-25 11:38:35
|
On 25 July 2016 at 13:18, Oleg Broytman <ph...@ph...> wrote: > > Hi! > > On Mon, Jul 25, 2016 at 01:03:33PM +0200, Neil Muller <drn...@gm...> wrote: > > On 25 July 2016 at 12:40, Oleg Broytman <ph...@ph...> wrote: > > > Does anybody here use SQLObject with Python 3? I started to believe it's > > > still impossible due to FormEncode not being ready for Python 3.4. But > > > our tests at Travis are passing. So I thing there is something wrong > > > significantly with the tests. Either Travis or Tox are betraying us. > > > > As far as I'm aware, no-one has reported significant issues with formencode > > 1.3.0 and python 3.4 . > > Formencode passes it's own test suite on python 3.4, and has for quite some > > time. > > https://travis-ci.org/formencode/formencode > > > > For the record, I am succesfully running a couple of programs using > > SQLObject 3 and python 3.4. > > > > The python3 Debian package build for sqlobject also runs the test suite, so > > it's not just passing the tests in the travis environment > > https://buildd.debian.org/status/fetch.php?pkg=sqlobject&arch=all&ver=3.0.0%2Bdfsg-2&stamp=1469130355 > > (although > > that's only with python 3.5) > > Thank you! Than there is something wrong with me: > > $ mkvirtualenv -p python3.4 SQLObject-py3 > Running virtualenv with interpreter /usr/bin/python3.4 > > $ pip3 install SQLObject > Collecting SQLObject > Using cached SQLObject-3.0.0-py2.py3-none-any.whl > Collecting PyDispatcher>=2.0.4 (from SQLObject) > Collecting FormEncode>=1.1.1 (from SQLObject) > Installing collected packages: PyDispatcher, FormEncode, SQLObject > Successfully installed FormEncode-1.3.0 PyDispatcher-2.0.5 SQLObject-3.0.0 > > $ python3.4 -c "from sqlobject import col" > Traceback (most recent call last): > File "<string>", line 1, in <module> > File "/home/phd/.virtualenvs/SQLObject-py3/lib/python3.4/site-packages/sqlobject/__init__.py", line 8, in <module> > from .col import * # noqa > File "/home/phd/.virtualenvs/SQLObject-py3/lib/python3.4/site-packages/sqlobject/col.py", line 31, in <module> > from formencode import compound, validators > File "/home/phd/.virtualenvs/SQLObject-py3/lib/python3.4/site-packages/formencode/__init__.py", line 3, in <module> > from formencode.api import ( > File "/home/phd/.virtualenvs/SQLObject-py3/lib/python3.4/site-packages/formencode/api.py", line 109, in <module> > class Invalid(Exception): > File "/home/phd/.virtualenvs/SQLObject-py3/lib/python3.4/site-packages/formencode/api.py", line 153, in Invalid > if unicode is not str: # Python 2 > NameError: name 'unicode' is not defined Formencode 1.3.0 builds with 2to3, and that should replace all the references to unicode (and it does for me locally - the corresponding line in my installed package is "if str is not str: # Python 2" Somehow, 2to3 isn't being run correctly in your case, which is puzzling -- Neil Muller drn...@gm... I've got a gmail account. Why haven't I become cool? |
|
From: Ian C. <gra...@gm...> - 2016-07-25 11:25:15
|
On Mon, Jul 25, 2016 at 6:18 AM, Oleg Broytman <ph...@ph...> wrote: > Hi! > > On Mon, Jul 25, 2016 at 01:03:33PM +0200, Neil Muller <drn...@gm...> wrote: >> On 25 July 2016 at 12:40, Oleg Broytman <ph...@ph...> wrote: >> > Does anybody here use SQLObject with Python 3? I started to believe it's >> > still impossible due to FormEncode not being ready for Python 3.4. But >> > our tests at Travis are passing. So I thing there is something wrong >> > significantly with the tests. Either Travis or Tox are betraying us. >> >> As far as I'm aware, no-one has reported significant issues with formencode >> 1.3.0 and python 3.4 . >> Formencode passes it's own test suite on python 3.4, and has for quite some >> time. >> https://travis-ci.org/formencode/formencode >> >> For the record, I am succesfully running a couple of programs using >> SQLObject 3 and python 3.4. >> >> The python3 Debian package build for sqlobject also runs the test suite, so >> it's not just passing the tests in the travis environment >> https://buildd.debian.org/status/fetch.php?pkg=sqlobject&arch=all&ver=3.0.0%2Bdfsg-2&stamp=1469130355 >> (although >> that's only with python 3.5) > > Thank you! Than there is something wrong with me: > > $ mkvirtualenv -p python3.4 SQLObject-py3 > Running virtualenv with interpreter /usr/bin/python3.4 > > $ pip3 install SQLObject > Collecting SQLObject > Using cached SQLObject-3.0.0-py2.py3-none-any.whl > Collecting PyDispatcher>=2.0.4 (from SQLObject) > Collecting FormEncode>=1.1.1 (from SQLObject) > Installing collected packages: PyDispatcher, FormEncode, SQLObject > Successfully installed FormEncode-1.3.0 PyDispatcher-2.0.5 SQLObject-3.0.0 > > $ python3.4 -c "from sqlobject import col" > Traceback (most recent call last): > File "<string>", line 1, in <module> > File "/home/phd/.virtualenvs/SQLObject-py3/lib/python3.4/site-packages/sqlobject/__init__.py", line 8, in <module> > from .col import * # noqa > File "/home/phd/.virtualenvs/SQLObject-py3/lib/python3.4/site-packages/sqlobject/col.py", line 31, in <module> > from formencode import compound, validators > File "/home/phd/.virtualenvs/SQLObject-py3/lib/python3.4/site-packages/formencode/__init__.py", line 3, in <module> > from formencode.api import ( > File "/home/phd/.virtualenvs/SQLObject-py3/lib/python3.4/site-packages/formencode/api.py", line 109, in <module> > class Invalid(Exception): > File "/home/phd/.virtualenvs/SQLObject-py3/lib/python3.4/site-packages/formencode/api.py", line 153, in Invalid > if unicode is not str: # Python 2 > NameError: name 'unicode' is not defined So current master (I think) probably has this fixed: https://github.com/formencode/formencode/blob/203bb759cd21ca54dddae9772157342d477b45cd/formencode/api.py#L155 You can see what it was in 1.3.0: https://github.com/formencode/formencode/blob/1.3.0/formencode/api.py#L153 That team is likely struggling with Python 3 compatibility, but I think they probably just need to release a bug fix for 1.3.0 for people using Python 3. I asked the FormEncode team for a new release: https://github.com/formencode/formencode/issues/104#issuecomment-234927875 |
|
From: Oleg B. <ph...@ph...> - 2016-07-25 11:34:14
|
On Mon, Jul 25, 2016 at 06:25:08AM -0500, Ian Cordasco <gra...@gm...> wrote: > So current master (I think) probably has this fixed: > https://github.com/formencode/formencode/blob/203bb759cd21ca54dddae9772157342d477b45cd/formencode/api.py#L155 > > You can see what it was in 1.3.0: > https://github.com/formencode/formencode/blob/1.3.0/formencode/api.py#L153 But how does it work in our tests? We use exactly that, FormEncode 1.3.0 from PyPI, not from their git repo: https://travis-ci.org/sqlobject/sqlobject/jobs/143714752 Oleg. -- Oleg Broytman http://phdru.name/ ph...@ph... Programmers don't die, they just GOSUB without RETURN. |
|
From: Oleg B. <ph...@ph...> - 2016-07-25 11:37:33
|
On Mon, Jul 25, 2016 at 06:25:08AM -0500, Ian Cordasco <gra...@gm...> wrote: > So current master (I think) probably has this fixed: > https://github.com/formencode/formencode/blob/203bb759cd21ca54dddae9772157342d477b45cd/formencode/api.py#L155 That works: $ pip3 install git+https://github.com/formencode/formencode Collecting git+https://github.com/formencode/formencode Cloning https://github.com/formencode/formencode to /tmp/pip-tr0kff4o-build Collecting six (from FormEncode==2.0.0a1) Downloading six-1.10.0-py2.py3-none-any.whl Installing collected packages: six, FormEncode Found existing installation: FormEncode 1.3.0 Uninstalling FormEncode-1.3.0: Successfully uninstalled FormEncode-1.3.0 Running setup.py install for FormEncode ... done Successfully installed FormEncode-2.0.0a1 six-1.10.0 $ python3.4 -c "from sqlobject import col" Oleg. -- Oleg Broytman http://phdru.name/ ph...@ph... Programmers don't die, they just GOSUB without RETURN. |
|
From: Christoph Z. <ci...@on...> - 2016-07-25 12:51:13
|
Am 25.07.2016 um 13:18 schrieb Oleg Broytman: > File "<stdin>", line 1, in <module> > NameError: name 'unicode' is not defined Hi Oleg, FormEncode 1.3 should run with Python 3, it uses 2to3. This error indicates that during installation the 2to3 tool did not run properly. Some have reported that this problem can be caused by cached wheels. In FormEncode 2, 2to3 is not used any more because of such issues, but I think there is no official release of FormEncode 2 yet. Anyway, if FormEncode 1.3 is installed properly, it should work. -- Christoph |
|
From: Oleg B. <ph...@ph...> - 2016-07-25 12:58:35
|
On Mon, Jul 25, 2016 at 02:51:03PM +0200, Christoph Zwerschke <ci...@on...> wrote:
> Am 25.07.2016 um 13:18 schrieb Oleg Broytman:
> > File "<stdin>", line 1, in <module>
> > NameError: name 'unicode' is not defined
>
> Hi Oleg,
>
> FormEncode 1.3 should run with Python 3, it uses 2to3. This error
> indicates that during installation the 2to3 tool did not run properly.
> Some have reported that this problem can be caused by cached wheels.
>
> In FormEncode 2, 2to3 is not used any more because of such issues, but I
> think there is no official release of FormEncode 2 yet.
>
> Anyway, if FormEncode 1.3 is installed properly, it should work.
>
> -- Christoph
Thank you very much! That increases assurance in our tests.
I've used star-destroyer to fix `import *`, fixed some tests manually
and need to be sure I didn't break anything, so I ran tests with Python
2.7 and 3.4 -- and oops, got these problems with FormEncode.
Now with FormEncode from git repo I can run tests -- and already
caught a minor bug.
Oleg.
--
Oleg Broytman http://phdru.name/ ph...@ph...
Programmers don't die, they just GOSUB without RETURN.
|
|
From: Ian C. <gra...@gm...> - 2016-07-25 12:55:54
|
On Mon, Jul 25, 2016 at 7:51 AM, Christoph Zwerschke <ci...@on...> wrote: > Am 25.07.2016 um 13:18 schrieb Oleg Broytman: > > File "<stdin>", line 1, in <module> > > NameError: name 'unicode' is not defined > > Hi Oleg, > > FormEncode 1.3 should run with Python 3, it uses 2to3. This error > indicates that during installation the 2to3 tool did not run properly. > Some have reported that this problem can be caused by cached wheels. > > In FormEncode 2, 2to3 is not used any more because of such issues, but I > think there is no official release of FormEncode 2 yet. > > Anyway, if FormEncode 1.3 is installed properly, it should work. So this is because FormEncode 1.3 claims it can provide a universal wheel (https://github.com/formencode/formencode/blob/1.3.0/setup.cfg#L29) but it cannot. A 1.3.1 release should be provided with universal = 0. This way when pip caches the wheel it produces, it tags it with py2 or py3 as appropriate. |
|
From: Ian C. <gra...@gm...> - 2016-07-25 12:59:16
|
On Mon, Jul 25, 2016 at 7:55 AM, Ian Cordasco <gra...@gm...> wrote: > On Mon, Jul 25, 2016 at 7:51 AM, Christoph Zwerschke <ci...@on...> wrote: >> Am 25.07.2016 um 13:18 schrieb Oleg Broytman: >> > File "<stdin>", line 1, in <module> >> > NameError: name 'unicode' is not defined >> >> Hi Oleg, >> >> FormEncode 1.3 should run with Python 3, it uses 2to3. This error >> indicates that during installation the 2to3 tool did not run properly. >> Some have reported that this problem can be caused by cached wheels. >> >> In FormEncode 2, 2to3 is not used any more because of such issues, but I >> think there is no official release of FormEncode 2 yet. >> >> Anyway, if FormEncode 1.3 is installed properly, it should work. > > So this is because FormEncode 1.3 claims it can provide a universal > wheel (https://github.com/formencode/formencode/blob/1.3.0/setup.cfg#L29) > but it cannot. A 1.3.1 release should be provided with universal = 0. > This way when pip caches the wheel it produces, it tags it with py2 or > py3 as appropriate. I submitted https://github.com/formencode/formencode/issues/117 to see if we can alleviate this. |
|
From: Oleg B. <ph...@ph...> - 2016-07-25 13:00:48
|
On Mon, Jul 25, 2016 at 07:55:48AM -0500, Ian Cordasco <gra...@gm...> wrote: > On Mon, Jul 25, 2016 at 7:51 AM, Christoph Zwerschke <ci...@on...> wrote: > > Am 25.07.2016 um 13:18 schrieb Oleg Broytman: > > > File "<stdin>", line 1, in <module> > > > NameError: name 'unicode' is not defined > > > > Hi Oleg, > > > > FormEncode 1.3 should run with Python 3, it uses 2to3. This error > > indicates that during installation the 2to3 tool did not run properly. > > Some have reported that this problem can be caused by cached wheels. > > > > In FormEncode 2, 2to3 is not used any more because of such issues, but I > > think there is no official release of FormEncode 2 yet. > > > > Anyway, if FormEncode 1.3 is installed properly, it should work. > > So this is because FormEncode 1.3 claims it can provide a universal > wheel (https://github.com/formencode/formencode/blob/1.3.0/setup.cfg#L29) > but it cannot. A 1.3.1 release should be provided with universal = 0. > This way when pip caches the wheel it produces, it tags it with py2 or > py3 as appropriate. I see you reported the problem at https://github.com/formencode/formencode/issues/117 Thanks! Oleg. -- Oleg Broytman http://phdru.name/ ph...@ph... Programmers don't die, they just GOSUB without RETURN. |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X