switch naming back from libmapnik2 -> libmapnik (also python) #941

Closed
springmeyer opened this Issue Nov 2, 2011 · 8 comments

Comments

Projects
None yet
5 participants
@springmeyer
Member

springmeyer commented Nov 2, 2011

/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:

  • packaging systems know how to handle multiple versions - lets let them do the heavy lifting on this
  • we do not anticipate another long period again where simultaneous testing for development like this will be needed
  • from source build systems that depend on mapnik should not have to adapt to mapnik2 naming (and mapnik3, 4, etc)
  • the namespacing was imperfect (because we did not want to rename the headers to #include </mapnik2/...> as this would have caused a lot of breakages)
  • sonaming should be used to handle library naming between different versions not the actual library basename.

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.

@springmeyer

This comment has been minimized.

Show comment
Hide comment
@springmeyer

springmeyer Nov 2, 2011

Member

I'll start with my:

+1 :)

Member

springmeyer commented Nov 2, 2011

I'll start with my:

+1 :)

@artemp

This comment has been minimized.

Show comment
Hide comment
@artemp

artemp Nov 2, 2011

Member

Yes, lets keep it simple :

+1

Member

artemp commented Nov 2, 2011

Yes, lets keep it simple :

+1

@dpaleino

This comment has been minimized.

Show comment
Hide comment
@dpaleino

dpaleino Nov 2, 2011

+1 from me too.

dpaleino commented Nov 2, 2011

+1 from me too.

@rcoup

This comment has been minimized.

Show comment
Hide comment
@rcoup

rcoup Nov 2, 2011

Member

+1 :)

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)

Member

rcoup commented Nov 2, 2011

+1 :)

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)

@kunitoki

This comment has been minimized.

Show comment
Hide comment
@kunitoki

kunitoki Nov 2, 2011

Member

+1 and +1 for rcoup idea too

Member

kunitoki commented Nov 2, 2011

+1 and +1 for rcoup idea too

@springmeyer

This comment has been minimized.

Show comment
Hide comment
@springmeyer

springmeyer Nov 3, 2011

Member

yep, good idea @rcoup

Member

springmeyer commented Nov 3, 2011

yep, good idea @rcoup

@ghost ghost assigned artemp Nov 22, 2011

@artemp

This comment has been minimized.

Show comment
Hide comment
@artemp

artemp Nov 23, 2011

Member

Done in 14700db
mapnik2 is still available but raises DeprecationWarning

Member

artemp commented Nov 23, 2011

Done in 14700db
mapnik2 is still available but raises DeprecationWarning

@artemp artemp closed this Nov 23, 2011

@dpaleino

This comment has been minimized.

Show comment
Hide comment
@dpaleino

dpaleino Nov 23, 2011

ACK, thanks!

I'll wait a release before doing this in Debian too :)

ACK, thanks!

I'll wait a release before doing this in Debian too :)

springmeyer pushed a commit that referenced this issue Mar 14, 2012

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment