Thread: [SQLObject] Proposed Plan for Porting to Python 3

Hey all,

I see there's been some discussion of late about porting the library
to support Python 3. I'm a *very occasional* user of SQLObject and
I've not contributed thus far, but I have some experience porting
code-bases to support Python 3. The following is the sum of my
experiences and is by no means absolute fact or the experiences of
others.

I'm personally of the opinion that having separate branches for Python
2 and Python 3 is a really bad idea. It works for some but it is way
too much overhead and it always ends up in something getting out of
sync. The best way forward is to have one codebase that works on
Python 2 and Python 3.

First, I've found it far easier to support Python 3 once Python 2.5
support has been dropped. It is possible to support Python 2.5 (pep8,
pyflakes, mccabe, and flake8 are all projects which do this) but it is
tricky. It would be up to the community whether it wants to support
2.5 or not and I really don't feel right in telling you to drop
support for it altogether (although planning that may be a good idea).

Second, a strategy that Alex Gaynor uses is to run flake8 under python
2 and python 3. A quick look at SQLObject's source makes me believe
this is suboptimal at this point. The code mostly complies with pep8
but would still have a lot of extraneous output generated by the pep8
tool that flake8 uses. The reason for using flake8 is that pyflakes
(which flake8 uses) compiles the code using the AST and when
compilation fails, it tells you for which file(s) it failed and where.
This will help us simply make the code *run* on Python 3.

Third, setting up a continuous integration system (like Travis CI) to
run the tests after every push and whenever someone submits a pull
request. The CI system can do the following:

- Run the tests on a specified version of Python (usually limited to
things like 2.6, 2.7, 3.2, 3.3, 3.4, pypy, etc. and not allowing for
granularity like 2.6.8 and 2.6.9)
- Run pyflakes (or flake8) on specified versions of Python
- Generating docs and ensuring they build properly
- Other goodies

This helps us catch regressions in Python 3 support or Python 2 support.

Fourth, using a library like six to help cover some common import or
string related problems in supporting Python 2 and 3 in a single
codebase.

~~

This is of course all predicated on the assumption that sqlobject's
dependencies support Python 3 as well, but I haven't looked into all
of them. It also is predicated on sqlobject wanting to wait (or not
wait) for those dependencies before adding support.

I've sent this email to see if I'm the only one interested in helping
with the "port". I definitely don't have the time to do this all by
myself and having about 4 or more people to help would be amazing.

Personally, I prefer working on GitHub if possible and I know the
repository is already there. I would be happy to help coordinate and
review pull requests there if people can help with this.

I'd love to hear everyone's feedback.

Thanks,
Ian

On 1 December 2014 at 16:53, Ian Cordasco <gra...@gm...> wrote:
> Hey all,
>
> This is of course all predicated on the assumption that sqlobject's
> dependencies support Python 3 as well, but I haven't looked into all
> of them. It also is predicated on sqlobject wanting to wait (or not
> wait) for those dependencies before adding support.

When I last looked (which was some time ago), formencode still didn't
have a python 3 compatible release, but that appeared to be the only
one still missing.

Several of the less commonly used database backends don't have python
3 versions as far as I know. sqlite and postgresql should both be
fine, though. MySQL's status is a bit murky since the original MySQLdb
hasn't been ported to python 3 yet but there are a number of forks of
it claim to support python 3, so it's presumably doable.

> I've sent this email to see if I'm the only one interested in helping
> with the "port". I definitely don't have the time to do this all by
> myself and having about 4 or more people to help would be amazing.

There's certainly interest in seeing sqlobject ported to python 3, and
I would be willing to help as time allows.

-- 
Neil Muller
drn...@gm...

I've got a gmail account. Why haven't I become cool?

I'd also be interested in helping out.

Hi!

On Mon, Dec 01, 2014 at 05:23:17PM +0200, Simon Cross <hod...@gm...> wrote:
> I'd also be interested in helping out.

   Tell me your Github nick, I'll add you to the team.

Oleg.
-- 
     Oleg Broytman            http://phdru.name/            ph...@ph...
           Programmers don't die, they just GOSUB without RETURN.

Hi!, Ian! Thank you!

On Mon, Dec 01, 2014 at 08:53:34AM -0600, Ian Cordasco <gra...@gm...> wrote:
> Hey all,
> 
> I see there's been some discussion of late about porting the library
> to support Python 3. I'm a *very occasional* user of SQLObject and
> I've not contributed thus far, but I have some experience porting
> code-bases to support Python 3. The following is the sum of my
> experiences and is by no means absolute fact or the experiences of
> others.
> 
> I'm personally of the opinion that having separate branches for Python
> 2 and Python 3 is a really bad idea. It works for some but it is way
> too much overhead and it always ends up in something getting out of
> sync. The best way forward is to have one codebase that works on
> Python 2 and Python 3.
> 
> First, I've found it far easier to support Python 3 once Python 2.5
> support has been dropped. It is possible to support Python 2.5 (pep8,
> pyflakes, mccabe, and flake8 are all projects which do this) but it is
> tricky. It would be up to the community whether it wants to support
> 2.5 or not and I really don't feel right in telling you to drop
> support for it altogether (although planning that may be a good idea).
> 
> Second, a strategy that Alex Gaynor uses is to run flake8 under python
> 2 and python 3. A quick look at SQLObject's source makes me believe
> this is suboptimal at this point. The code mostly complies with pep8
> but would still have a lot of extraneous output generated by the pep8
> tool that flake8 uses. The reason for using flake8 is that pyflakes
> (which flake8 uses) compiles the code using the AST and when
> compilation fails, it tells you for which file(s) it failed and where.
> This will help us simply make the code *run* on Python 3.
> 
> Third, setting up a continuous integration system (like Travis CI) to
> run the tests after every push and whenever someone submits a pull
> request. The CI system can do the following:
> 
> - Run the tests on a specified version of Python (usually limited to
> things like 2.6, 2.7, 3.2, 3.3, 3.4, pypy, etc. and not allowing for
> granularity like 2.6.8 and 2.6.9)
> - Run pyflakes (or flake8) on specified versions of Python
> - Generating docs and ensuring they build properly
> - Other goodies
> 
> This helps us catch regressions in Python 3 support or Python 2 support.
> 
> Fourth, using a library like six to help cover some common import or
> string related problems in supporting Python 2 and 3 in a single
> codebase.
> 
> ~~
> 
> This is of course all predicated on the assumption that sqlobject's
> dependencies support Python 3 as well, but I haven't looked into all
> of them. It also is predicated on sqlobject wanting to wait (or not
> wait) for those dependencies before adding support.
> 
> I've sent this email to see if I'm the only one interested in helping
> with the "port". I definitely don't have the time to do this all by
> myself and having about 4 or more people to help would be amazing.
> 
> Personally, I prefer working on GitHub if possible and I know the
> repository is already there. I would be happy to help coordinate and
> review pull requests there if people can help with this.

   What's your Github login? I'll add you to the team.

> I'd love to hear everyone's feedback.
> 
> Thanks,
> Ian

Oleg.
-- 
     Oleg Broytman            http://phdru.name/            ph...@ph...
           Programmers don't die, they just GOSUB without RETURN.

Ian, if you publish here the list of current tasks people could select
some tasks or subtasks to help you.

Oleg.
-- 
     Oleg Broytman            http://phdru.name/            ph...@ph...
           Programmers don't die, they just GOSUB without RETURN.

Hi!

On Mon, Dec 01, 2014 at 05:15:52PM +0200, Neil Muller <drn...@gm...> wrote:
> On 1 December 2014 at 16:53, Ian Cordasco <gra...@gm...> wrote:
> > Hey all,
> >
> > This is of course all predicated on the assumption that sqlobject's
> > dependencies support Python 3 as well, but I haven't looked into all
> > of them. It also is predicated on sqlobject wanting to wait (or not
> > wait) for those dependencies before adding support.
> 
> When I last looked (which was some time ago), formencode still didn't
> have a python 3 compatible release, but that appeared to be the only
> one still missing.

   Yes to both points.

> There's certainly interest in seeing sqlobject ported to python 3, and
> I would be willing to help as time allows.

   What's your Github nick? I'll add you to the team.

Oleg.
-- 
     Oleg Broytman            http://phdru.name/            ph...@ph...
           Programmers don't die, they just GOSUB without RETURN.

On Mon, Dec 1, 2014 at 2:47 PM, Oleg Broytman <ph...@ph...> wrote:
> Hi!, Ian! Thank you!
>

You're welcome! I derive immense joy from seeing awesome projects make
the leap, so I'm really happy to see people enthusiastic about this.

> On Mon, Dec 01, 2014 at 08:53:34AM -0600, Ian Cordasco <gra...@gm...> wrote:
>> Hey all,
>>
>> I see there's been some discussion of late about porting the library
>> to support Python 3. I'm a *very occasional* user of SQLObject and
>> I've not contributed thus far, but I have some experience porting
>> code-bases to support Python 3. The following is the sum of my
>> experiences and is by no means absolute fact or the experiences of
>> others.
>>
>> I'm personally of the opinion that having separate branches for Python
>> 2 and Python 3 is a really bad idea. It works for some but it is way
>> too much overhead and it always ends up in something getting out of
>> sync. The best way forward is to have one codebase that works on
>> Python 2 and Python 3.
>>
>> First, I've found it far easier to support Python 3 once Python 2.5
>> support has been dropped. It is possible to support Python 2.5 (pep8,
>> pyflakes, mccabe, and flake8 are all projects which do this) but it is
>> tricky. It would be up to the community whether it wants to support
>> 2.5 or not and I really don't feel right in telling you to drop
>> support for it altogether (although planning that may be a good idea).
>>
>> Second, a strategy that Alex Gaynor uses is to run flake8 under python
>> 2 and python 3. A quick look at SQLObject's source makes me believe
>> this is suboptimal at this point. The code mostly complies with pep8
>> but would still have a lot of extraneous output generated by the pep8
>> tool that flake8 uses. The reason for using flake8 is that pyflakes
>> (which flake8 uses) compiles the code using the AST and when
>> compilation fails, it tells you for which file(s) it failed and where.
>> This will help us simply make the code *run* on Python 3.
>>
>> Third, setting up a continuous integration system (like Travis CI) to
>> run the tests after every push and whenever someone submits a pull
>> request. The CI system can do the following:
>>
>> - Run the tests on a specified version of Python (usually limited to
>> things like 2.6, 2.7, 3.2, 3.3, 3.4, pypy, etc. and not allowing for
>> granularity like 2.6.8 and 2.6.9)
>> - Run pyflakes (or flake8) on specified versions of Python
>> - Generating docs and ensuring they build properly
>> - Other goodies
>>
>> This helps us catch regressions in Python 3 support or Python 2 support.
>>
>> Fourth, using a library like six to help cover some common import or
>> string related problems in supporting Python 2 and 3 in a single
>> codebase.
>>
>> ~~
>>
>> This is of course all predicated on the assumption that sqlobject's
>> dependencies support Python 3 as well, but I haven't looked into all
>> of them. It also is predicated on sqlobject wanting to wait (or not
>> wait) for those dependencies before adding support.
>>
>> I've sent this email to see if I'm the only one interested in helping
>> with the "port". I definitely don't have the time to do this all by
>> myself and having about 4 or more people to help would be amazing.
>>
>> Personally, I prefer working on GitHub if possible and I know the
>> repository is already there. I would be happy to help coordinate and
>> review pull requests there if people can help with this.
>
>    What's your Github login? I'll add you to the team.

sigmavirus24

>
>> I'd love to hear everyone's feedback.
>>
>> Thanks,
>> Ian
>
> Oleg.
> --
>      Oleg Broytman            http://phdru.name/            ph...@ph...
>            Programmers don't die, they just GOSUB without RETURN.
>
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
> http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
> _______________________________________________
> sqlobject-discuss mailing list
> sql...@li...
> https://lists.sourceforge.net/lists/listinfo/sqlobject-discuss

On Mon, Dec 01, 2014 at 02:58:20PM -0600, Ian Cordasco <gra...@gm...> wrote:
> >> Personally, I prefer working on GitHub if possible and I know the
> >> repository is already there. I would be happy to help coordinate and
> >> review pull requests there if people can help with this.
> >
> >    What's your Github login? I'll add you to the team.
> 
> sigmavirus24

   Sent an invitation. Welcome on board!

   I created a team called "developers" and gave it write access to
sqlobject/sqlobject repository. You'll be a member of the team.

Oleg.
-- 
     Oleg Broytman            http://phdru.name/            ph...@ph...
           Programmers don't die, they just GOSUB without RETURN.

On 1 December 2014 at 22:49, Oleg Broytman <ph...@ph...> wrote:
>
>    What's your Github nick? I'll add you to the team.

Mine is drnlm


-- 
Neil Muller
drn...@gm...

I've got a gmail account. Why haven't I become cool?

On Tue, Dec 02, 2014 at 12:27:29AM +0200, Neil Muller <drn...@gm...> wrote:
> On 1 December 2014 at 22:49, Oleg Broytman <ph...@ph...> wrote:
> >
> >    What's your Github nick? I'll add you to the team.
> 
> Mine is drnlm

   Sent an invitation. Welcome on board!

Oleg.
-- 
     Oleg Broytman            http://phdru.name/            ph...@ph...
           Programmers don't die, they just GOSUB without RETURN.

Hi!

On Mon, Dec 01, 2014 at 08:53:34AM -0600, Ian Cordasco <gra...@gm...> wrote:
> Third, setting up a continuous integration system (like Travis CI) to
> run the tests after every push and whenever someone submits a pull
> request. The CI system can do the following:

   I have always wanted to learn Travis CI. See my first attempt at
creating .travis.yml (attached).

Oleg.
-- 
     Oleg Broytman            http://phdru.name/            ph...@ph...
           Programmers don't die, they just GOSUB without RETURN.

On Sun, Dec 7, 2014 at 1:06 AM, Oleg Broytman <ph...@ph...> wrote:
> On Fri, Dec 05, 2014 at 08:38:31PM +0100, Oleg Broytman <ph...@ph...> wrote:
>> datetime test fails with MySQL:
>
>    Got it: MySQL doesn't support microseconds until 5.6.4, Travis runs
> 5.5, so the error can be ignored.
>    I will work on skipping the test on backends that don't support
> microseconds and adapt SQLObject to MySQL 5.6.4+ (date/time columns must
> be created with precision: TIME(6) instead of TIME and so on).

I think you can use apt (e.g., apt-get, apt-cache, etc.) on Travis and
you can probably upgrade it to the version of MySQL that you would
like to test against.

I'm  having trouble finding it in the docs though so I'll have to see
if I can find other projects that do this.

> Oleg.
> --
>      Oleg Broytman            http://phdru.name/            ph...@ph...
>            Programmers don't die, they just GOSUB without RETURN.
>
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
> _______________________________________________
> sqlobject-discuss mailing list
> sql...@li...
> https://lists.sourceforge.net/lists/listinfo/sqlobject-discuss

On Sun, Dec 07, 2014 at 08:06:29AM +0100, Oleg Broytman <ph...@ph...> wrote:
>    MySQL doesn't support microseconds until 5.6.4, Travis runs
> 5.5, so the error can be ignored.
>    I will work on skipping the test on backends that don't support
> microseconds and adapt SQLObject to MySQL 5.6.4+ (date/time columns must
> be created with precision: TIME(6) instead of TIME and so on).

   Done, all tests are now passed, see
https://travis-ci.org/sqlobject/sqlobject/branches

   I added the test status images at PyPI, see
https://pypi.python.org/pypi/SQLObject/1.5.4
https://pypi.python.org/pypi/SQLObject/1.6.2
https://pypi.python.org/pypi/SQLObject/1.7.0
https://pypi.python.org/pypi/SQLObject/2.0.0a2dev-20141028
   Need to add them to the docs.

   There is one sporadic bug related to round number of microseconds
like 83500: some parts of code think it's 0.0835 (83500), and some think
it's 0.835 (835000). See the traceback near the end of
https://travis-ci.org/sqlobject/sqlobject/jobs/42989776
   I hope to fix the bug. Then I'm going to release 2.0 beta 1 and
create a separate branch for 2.0. Then master will be free for working
on Py3 compatibility.

Oleg.
-- 
     Oleg Broytman            http://phdru.name/            ph...@ph...
           Programmers don't die, they just GOSUB without RETURN.

On Wed, Dec 10, 2014 at 12:55:36AM +0100, Oleg Broytman <ph...@ph...> wrote:
> On Sun, Dec 07, 2014 at 08:06:29AM +0100, Oleg Broytman <ph...@ph...> wrote:
> >    MySQL doesn't support microseconds until 5.6.4, Travis runs
> > 5.5, so the error can be ignored.
> >    I will work on skipping the test on backends that don't support
> > microseconds and adapt SQLObject to MySQL 5.6.4+ (date/time columns must
> > be created with precision: TIME(6) instead of TIME and so on).
> 
>    Done, all tests are now passed, see
> https://travis-ci.org/sqlobject/sqlobject/branches

   BTW I added version test to MySQLConnection and test MariaDB >= 5.3.0
or MySQL >= 5.6.4.

Oleg.
-- 
     Oleg Broytman            http://phdru.name/            ph...@ph...
           Programmers don't die, they just GOSUB without RETURN.

On Wed, Dec 10, 2014 at 12:55:36AM +0100, Oleg Broytman <ph...@ph...> wrote:
>    There is one sporadic bug related to round number of microseconds
> like 83500: some parts of code think it's 0.0835 (83500), and some think
> it's 0.835 (835000). See the traceback near the end of
> https://travis-ci.org/sqlobject/sqlobject/jobs/42989776

   Fixed. The problem was in converter.py: I used "%d" format to convert
microseconds to SQL strings where it really must be "%06d".

   SQLObject 2.0 beta 1 was just released. All tests passed, see

   https://travis-ci.org/sqlobject/sqlobject/builds/43712156

Oleg.
-- 
     Oleg Broytman            http://phdru.name/            ph...@ph...
           Programmers don't die, they just GOSUB without RETURN.

On Wed, Dec 10, 2014 at 12:55:36AM +0100, Oleg Broytman <ph...@ph...> wrote:
> create a separate branch for 2.0. Then master will be free for working
> on Py3 compatibility.

   Done: I created a new branch 2.0 and edited master to be 3.0
pre-alpha.

   Ian, the master is waiting for you! ;-)

Oleg.
-- 
     Oleg Broytman            http://phdru.name/            ph...@ph...
           Programmers don't die, they just GOSUB without RETURN.

Awesome!
On Dec 11, 2014 8:10 AM, "Oleg Broytman" <ph...@ph...> wrote:

> On Wed, Dec 10, 2014 at 12:55:36AM +0100, Oleg Broytman <ph...@ph...>
> wrote:
> > create a separate branch for 2.0. Then master will be free for working
> > on Py3 compatibility.
>
>    Done: I created a new branch 2.0 and edited master to be 3.0
> pre-alpha.
>
>    Ian, the master is waiting for you! ;-)
>
> Oleg.
> --
>      Oleg Broytman            http://phdru.name/            ph...@ph...
>            Programmers don't die, they just GOSUB without RETURN.
>
>
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
>
> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
> _______________________________________________
> sqlobject-discuss mailing list
> sql...@li...
> https://lists.sourceforge.net/lists/listinfo/sqlobject-discuss
>

On Thu, Dec 11, 2014 at 8:13 AM, Ian Cordasco
<gra...@gm...> wrote:
> Awesome!
>
> On Dec 11, 2014 8:10 AM, "Oleg Broytman" <ph...@ph...> wrote:
>>
>> On Wed, Dec 10, 2014 at 12:55:36AM +0100, Oleg Broytman <ph...@ph...>
>> wrote:
>> > create a separate branch for 2.0. Then master will be free for working
>> > on Py3 compatibility.
>>
>>    Done: I created a new branch 2.0 and edited master to be 3.0
>> pre-alpha.
>>
>>    Ian, the master is waiting for you! ;-)
>>
>> Oleg.
>> --
>>      Oleg Broytman            http://phdru.name/            ph...@ph...
>>            Programmers don't die, they just GOSUB without RETURN.
>>
>>
>> ------------------------------------------------------------------------------
>> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
>> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
>> with Interactivity, Sharing, Native Excel Exports, App Integration & more
>> Get technology previously reserved for billion-dollar corporations, FREE
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
>> _______________________________________________
>> sqlobject-discuss mailing list
>> sql...@li...
>> https://lists.sourceforge.net/lists/listinfo/sqlobject-discuss


So I finally got some time. I've put together
https://github.com/sqlobject/sqlobject/pull/1 so we can have something
that everyone can reproduce with. It's uncovered a couple bugs in the
tests (specifically around depending on hash/dictionary ordering).
That aside, there are a bunch of problems pyflakes has with the
code-base but just running the py34 version has found syntactical
incompatibilities that should be easy to fix. I'd like to do that in a
separate pull request.

I'd like everyone's thoughts on this. This particular strategy is
something a lot of projects are beginning to use. I feel like we
should also add some documentation around running the tests
(especially for people who don't deal with postgres often (like me)
;)).

Cheers,
Ian

Looks good?

I was a bit surprised by the "/usr/bin/py.test-$TRAVIS_PYTHON_VERION".
I would have thought that could just be "py.test"?

Hi!

On Thu, Dec 04, 2014 at 09:38:04AM +0200, Simon Cross <hod...@gm...> wrote:
> Looks good?
> 
> I was a bit surprised by the "/usr/bin/py.test-$TRAVIS_PYTHON_VERION".
> I would have thought that could just be "py.test"?

   But how do you run test with different python versions?

python:
  - "2.6"
  - "2.7"

   makes Travis to repeat the tests with different versions, so the test
script has either run

python-$TRAVIS_PYTHON_VERSION /usr/bin/py.test

   or

/usr/bin/py.test-$TRAVIS_PYTHON_VERSION

   At least that how I understand it. I am new to Travis.

Oleg.
-- 
     Oleg Broytman            http://phdru.name/            ph...@ph...
           Programmers don't die, they just GOSUB without RETURN.

Travis runs Python builds inside a virtualenv for the selected Python
version, with a few things pre-installed.

On Thu, Dec 04, 2014 at 10:31:48AM +0200, Simon Cross <hod...@gm...> wrote:
> Travis runs Python builds inside a virtualenv for the selected Python
> version, with a few things pre-installed.

   Yes, got it. /usr/bin/python will be either python2.6 of 2.7. Thank
you for spotting!

Oleg.
-- 
     Oleg Broytman            http://phdru.name/            ph...@ph...
           Programmers don't die, they just GOSUB without RETURN.

On Thu, Dec 4, 2014 at 12:13 AM, Oleg Broytman <ph...@ph...> wrote:
> Hi!
>
> On Mon, Dec 01, 2014 at 08:53:34AM -0600, Ian Cordasco <gra...@gm...> wrote:
>> Third, setting up a continuous integration system (like Travis CI) to
>> run the tests after every push and whenever someone submits a pull
>> request. The CI system can do the following:
>
>    I have always wanted to learn Travis CI. See my first attempt at
> creating .travis.yml (attached).
>
> Oleg.
> --
>      Oleg Broytman            http://phdru.name/            ph...@ph...
>            Programmers don't die, they just GOSUB without RETURN.
>
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
> _______________________________________________
> sqlobject-discuss mailing list
> sql...@li...
> https://lists.sourceforge.net/lists/listinfo/sqlobject-discuss
>

If you make a branch in the repository and (one of us [1]) enables
Travis then we can test the config to see how it works :)

--
Ian

[1]: I'm not certain if I can modify settings on the repository or not
and haven't yet checked.

Hi!

On Sun, Dec 07, 2014 at 12:10:16PM -0600, Ian Cordasco <gra...@gm...> wrote:
> On Sun, Dec 7, 2014 at 1:06 AM, Oleg Broytman <ph...@ph...> wrote:
> > On Fri, Dec 05, 2014 at 08:38:31PM +0100, Oleg Broytman <ph...@ph...> wrote:
> >> datetime test fails with MySQL:
> >
> >    Got it: MySQL doesn't support microseconds until 5.6.4, Travis runs
> > 5.5, so the error can be ignored.
> >    I will work on skipping the test on backends that don't support
> > microseconds and adapt SQLObject to MySQL 5.6.4+ (date/time columns must
> > be created with precision: TIME(6) instead of TIME and so on).
> 
> I think you can use apt (e.g., apt-get, apt-cache, etc.) on Travis and
> you can probably upgrade it to the version of MySQL that you would
> like to test against.

   I'd certainly like to test against both old and new versions.

> I'm  having trouble finding it in the docs though so I'll have to see
> if I can find other projects that do this.

   Something like this:
http://docs.travis-ci.com/user/installing-dependencies/
   ?

Oleg.
-- 
     Oleg Broytman            http://phdru.name/            ph...@ph...
           Programmers don't die, they just GOSUB without RETURN.