[gdal-dev] Participating on gdal2tiles

[Grégory Bataille]

Yes it is. There was a commit on the test_gdal2tiles.py changing the
checksum values for test 1 :)

that's odd, it's pyflakes that is throwing me those warnings... well flake8
actually that is pyflakes + pep8. I'll have a look anyway.
And yes, the style commits need to be separate, no worries.

I did launch the vagrant by commenting this missing script. Now what is the
vagrant box supposed to do? my understanding is that is comes with gdal
installed (from trunk?)
I think the gdal2tiles.py test (and maybe some other python ones) are not
working in the vagrant box because those tests are looking for scripts to
test (gdal2tiles.py for example) in relative from the test file
test_gdal2tiles.py and because the Vagrantfile only maps the autotest
folder from the host to the client VM, the source for those python scripts
is not available in the VM.
Is it on purpose? would you see any issue mapping the source gdal folder
inside the vagrant box next to the autotest folder?

Sorry for the questions, it's always hard to enter into a project.

Last one actually for this mail:
I have an issue on a particular image. To test a fix (and non-regression in
the future) I can either try to do some mocking (but seeing how
gdal2tiles.py is not very modular, that might prove a nightmare) or use
some specific image that I know present the issue. If I want to test based
on an image, is it an ok practice to put the image in the repo (I can see
that there are several already but that doesn't seem like a great idea to
me). Any other common storage place (AWS S3 or whatever) that you would
have available or recommend otherwise?

Thanks


---
Gregory Bataille

On Sun, Jan 22, 2017 at 11:09 AM, Even Rouault <even.rouault at spatialys.com>
wrote:

> On dimanche 22 janvier 2017 09:00:59 CET Grégory Bataille wrote:
>
> > Hey all,
>
> >
>
> > 2 questions:
>
> > seeing that it's complex to build trunk on mac (and that some recent
>
> > changes have an impact on gdal2tiles output),
>
>
>
> is it ? You can have a look at the scripts in ci/travis/osx used for the
> OsX target on Travis-CI. They probably don't drag all dependencies though.
>
>
>
> > I wanted to setup the vagrant
>
> > box, but I get this error. Any clue?
>
>
>
> I've just committed the missing file. Was missing a svn add at some point
> during a branch merge.
>
>
>
> >
>
> > Second question: is there a python style-guide?
>
>
>
> Not that much. https://trac.osgeo.org/gdal/wiki/rfc8_devguide just
> mentions:
>
> """
>
> * All Python code in autotest, swig/python/scripts and swig/python/samples
> should pass OK with the Pyflakes checker (version used currently: 0.8.1).
> This is asserted by Travis-CI jobs
>
> * Python code should be written to be compatible with both Python 2 and
> Python 3.
>
> """
>
>
>
> > I can see some consistency
>
> > in the way the code is written but it's not following the PEP8 community
>
> > standard and my editor is growing red spots all over the place. Any
> concern
>
> > if I try to correct that bit by bit to PEP8?
>
>
>
> I don't have a strong personal opinon about PEP8 vs non-PEP8, but it seems
> that many Python projects enforce PEP8 compliance, so why not. The only
> thing to be careful with is to separate pure style change commits from
> functional change commits. Otherwise it is a history mess.
>
>
>
> Even
>
>
>
> --
>
> Spatialys - Geospatial professional services
>
> http://www.spatialys.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20170122/e69b6ef4/attachment-0001.html>