Python3.4 on Travis-CI

[psi29a]

Collecting coverage
  Using cached coverage-4.0.1.tar.gz
Collecting numpy
  Downloading numpy-1.10.1.tar.gz (4.0MB)
Collecting pygdal==1.10.0.1
  Downloading pygdal-1.10.0.1.tar.gz (314kB)
    Complete output from command python setup.py egg_info:
    Traceback (most recent call last):
      File "<string>", line 20, in <module>
      File "/tmp/pip-build-_3ifdr62/pygdal/setup.py", line 61
        print 'GDAL prefix from environment variable %s' % ENV_GDALHOME
                                                       ^
    SyntaxError: Missing parentheses in call to 'print'

This version of PyGDAL doesn't support Python3. I checked and later versions do support Python3. However none of these versions exist for Ubuntu Precise, thus not for Travis-CI.

The only solution I see so far is to backport one of the newer python3 compatible packages to Precise. I'll host it on my private PPA for now along with the mess of other backported Precise packages. ;)

This is required for us to test imex/export functionality.

[psi29a]

https://travis-ci.org/Mindwerks/worldengine/jobs/85204772

[tcld]

What is pygdal used for? Could it maybe be replaced? And why is it optional?

EDIT: Oh, this is only for the tests and not the user?

EDIT2: @psi29a Thank you for the explanation. I will shut up then.^^

[psi29a]

this is for imex :)

in order to export the heightmap to any format known to man.

If you don't have it, it won't be used and will say so.

[tcld]

I installed GDAL since I couldn't get PyGDAL to run. That wasn't trivial but it works.

[psi29a]

Totally not trivial which is why I depend on PyGDAL which makes it easier. That you're having problems with it is something we need to fix. What exactly is the problem?

Normally you just need to have libgdal-dev installed on your system, then pip install pygdal should just work.

[tcld]

(venvpygdal)tcl@tcl-main:.../Worldengine/master$ pip3.4 install pygdal
Collecting pygdal
  Using cached pygdal-1.11.2.1.tar.gz
    Complete output from command python setup.py egg_info:
    Traceback (most recent call last):
      File "<string>", line 20, in <module>
      File "/tmp/pip-build-tiy_2kcr/pygdal/setup.py", line 61
        print 'GDAL prefix from environment variable %s' % ENV_GDALHOME
                                                       ^
    SyntaxError: Missing parentheses in call to 'print'

Maybe it is the specific version I am using, but this one is not compatible with Python 3, it seems. (libgdal 1.11.2 is installed)

This is what I did to get GDAL itself going (under Ubuntu):

#added a repo to be able to access the newest version
$ sudo apt-add-repository ppa:ubuntugis/ubuntugis-unstable
$ sudo apt-get update
$ sudo apt-get install libgdal-dev #installed 1.11.2

#switch to venv
$ virtualenv venv
$ source venv/bin/activate

(venv) $ export CPLUS_INCLUDE_PATH=/usr/include/gdal
(venv) $ export C_INCLUDE_PATH=/usr/include/gdal
(venv) $ pip install GDAL==1.11.2

Took a while to figure out but at least I don't have to go around and start fixing packaged code.

[psi29a]

Ah yes, that is what I'm fighting against now... and the reason for this thread. hahahaha!

It is fixed upstream here:
https://github.com/dezhin/pygdal/blob/master/setup.py#L61

Just waiting for a new release.

Another thing is that ppa:ubuntugis/ubuntugis-* doesn't provide any new releases for precise... so we're stuck!

Like I said, I'll likely have to maintain my own libgdal-dev package on my PPA.

I'm glad you worked around it for now. Another reason why I added GDAL support as optional... ;)

[tcld]

GDAL is very powerful, so I guess it is nice to have. Although currently it is only used to export elevation maps, which with the likely upcoming support of 16 Bit grayscale PNGs is not too critical anymore.

[psi29a]

It would be nice to abuse GDAL for exporting other things from our world file. There is also import functionality that would be interesting as well, but is a lower priority.

Thank you again for adding the list of supported formats to the CLI hint/help for the --export flag. :)

[tcld]

Well, you will have to digest all of my other numpy-code first to get to that bit. ;P

[psi29a]

yeah... about that... which one first?

Why not just all in one?

[tcld]

This one would be the first: #138
This one second: #141

They do touch different things, that's why I kept them separate. I would suggest starting with 138 since then 141 will be a lot less code to look at before a merge. :) (But if you think 141 is ready, you can just use that, of course.)