test_notebooks

[BibMartin]

Create a test_notebooks test file that runs every notebook in folium/examples.

This will also enable to convert these notebook to markdown for enriching the docs.

[ocefpaf]

We should move those to requirements-dev.txt

[BibMartin]

Provided they are in requirements-dev.txt, can we remove this line ?
(I don't know what travis_retry does).

[ocefpaf]

Provided they are in requirements-dev.txt, can we remove this line ?

Yep.

(I don't know what travis_retry does).

Exactly what the name says. It re-tries a few times. (Good for stuff that might hang up on you like file downloads.)

[ocefpaf]

Create a test_notebooks test file that runs every notebook in folium/examples.

I am 👍 to this

This will also enable to convert these notebook to markdown for enriching the docs.

But that a look at nbsphinx before going forward. Maybe we already have what we need there.

Overall comments:

• The notebooks diffs are hard to interpret, but I guess you are just doing some editing and or running them, right?
• We can drop the Python 3.3, but I have no idea what is going on with Python 2.7! I will take a second look soon.

Thanks!

[BibMartin]

But that a look at nbsphinx before going forward. Maybe we already have what we need there.

Yes and no ; I'm not sure nbsphinx can be embedded in the tests routines.
And it seems nbsphinx requires pandoc that's more difficult to install (apt-get) (as far as I know).

The notebooks diffs are hard to interpret, but I guess you are just doing some editing and or running them, right?

Yes, there are some transformations to illustrate the new API. For example:

mmap.simple_marker(...)

has been replaced by

folium.Marker(...).add_to(mmap)

We can drop the Python 3.3

Yes, it would simplify the problem, if it's not needed anymore.

but I have no idea what is going on with Python 2.7! I will take a second look soon.

I'll try to understand that this WE.

[ocefpaf]

Let's just drop Python 3.3 support.

[ocefpaf]

Yes and no ; I'm not sure nbsphinx can be embedded in the tests routines.
And it seems nbsphinx requires pandoc that's more difficult to install (apt-get) (as far as I know).

OK. Let's leave nbsphinx for another day. (Although pandoc should be available in conda. I will see what I can do about that.)

but I have no idea what is going on with Python 2.7! I will take a second look soon.

I'll try to understand that this WE.

Don't worry to much. Let's just skip the Python 2.7 notebooks tests for now.

[BibMartin]

Well, it can be interesting to test the notebooks and generate them in the docs.
But it seems the way I did it is full of drawbacks:

• Python 2.7 and 3.3 don't work for 2 different (unknow ?) reasons
• Tests are much longer to run
• requirements-dev increases much
• .travis.yml is becoming complicated
• I'm not able to reproduce Travis's fails (maybe this can be overcome)

Finally, I'm not even sure that this PR is a good idea.

Another way of having (almost) the same result would be:

• Forget about running the notebooks in the tests
• Create a script the runs and transforms the notebooks to markdown when building the docs (with nbsphinx eventually)
• Provide a requirements-docbuild.txt that contains the larger dependencies.

Thus the notebooks would not be tested at every PR, but only when one builds the doc.

[ocefpaf]

We can use an if clause in .travis.yaml to run notebook tests only for Python 3.4. I would like to see notebook test at every PR even at the cost of longer Travis-CI runs. (We broke folium many times in the past because we merged PRs without testing them in a notebook.)

[BibMartin]

@ocefpaf
I think this PR is big enough to be merged.
I'll try to do another PR to finish doctrings' TODO.
Then we're done, aren't we ?

[ocefpaf]

I think this PR is big enough to be merged.

👍

I'll try to do another PR to finish doctrings' TODO.

Don't worry too much. We have enough for a release.

Then we're done, aren't we?

Done? Never! Ready for a release? We were probably good enough a few PRs ago 😜