You can clone with
/cc @rcoup, @dpaleino, @artemp for comments.
During the large refactoring push and testing period after merging the mapnik2 codebase into mainline trunk it was very useful for development to ease the ability to run both mapnik 0.7.x and mapnik 2.x together simultaneously, and this was done by adding a 2 to the library name and the python module.
We should now switch back to normal naming for the next release (2.0.1) and all that follow. The reasons are plenty:
The downside of course is that many users in python are now used to doing import mapnik2, but we can reach out to communicate this switch back and hopefully this will be a lesser evil if we move on this now.
I'll start with my:
Yes, lets keep it simple :
+1 from me too.
I'd suggest we leave the mapnik2 package as a shim around mapnik for the python bindings, and make it raise a deprecation warning (ie. go back to only having a mapnik package at v3)
+1 and +1 for rcoup idea too
yep, good idea @rcoup
Done in 14700db
mapnik2 is still available but raises DeprecationWarning
I'll wait a release before doing this in Debian too :)
backport 'switch naming back from libmapnik2 -> libmapnik (also pytho…
…n)' and remove svn traces (refs #941)