Opened 12 years ago

Closed 10 years ago

#37995 closed defect (fixed)

mapnik and py26-mapnik

Reported by: ryandesign (Ryan Carsten Schmidt) Owned by: stromnov (Andrey Stromnov)
Priority: Normal Milestone:
Component: ports Version:
Keywords: Cc: bpanulla (Brian Panulla), dbsgeo@…, cooljeanius (Eric Gallager), petrrr
Port: mapnik py26-mapnik

Description

What is the situation with mapnik and py26-mapnik? Why do both exist? mapnik appears to be current while py26-mapnik is vastly out of date and does not build and has several tickets filed against it and is no longer being maintained by its maintainer. Should py26-mapnik be replaced_by mapnik?

Change History (13)

comment:1 Changed 12 years ago by stromnov (Andrey Stromnov)

Yes, I think that py26-mapnik should be replaced by mapnik.

And mapnik is a C++ GIS library with optional python bindings (and other plugins), so mapnik must be in gis/mapnik, but not in python/py*-mapnik.

comment:2 Changed 12 years ago by bpanulla (Brian Panulla)

There were pretty serious changes to the Mapnik API for version 2. Would "replaced_by" cause an automatic upgrade from Mapnik 0.7 (as in py26-mapnik) to Mapnik 2.1?

comment:3 Changed 12 years ago by ryandesign (Ryan Carsten Schmidt)

Yes, that would be the purpose of adding that directive.

If there is a reason why an older mapnik should be kept, then it should be renamed from py26-mapnik to mapnik07 or something.

comment:4 Changed 10 years ago by cooljeanius (Eric Gallager)

Cc: egall@… added

Cc Me!

comment:5 Changed 10 years ago by petrrr

Cc: petr@… added

Cc Me!

comment:6 Changed 10 years ago by petrrr

Could we get rid of the py26-mapnik code by now? It is quite dated now, and mapnik is around for some while.

Not sure I understand the issue regarding replaced_by mapnik, why this should create any problems due to the API changes. Mapnik seems to have no dependents. The only issue I could think of is that py26-mapnik would correspond to mapnik +python26, while the default is +python27.

So what would be a smooth exit strategy?

comment:7 Changed 10 years ago by petrrr

See also tickets:

  • #30187 (request for a py27-mapnik port) which probably should not be implemented;
  • #32452 enhancement to py26-mapnik;
  • #35323 defect py26-mapnik: undefined symbols boost::system::generic_category boost::system::system_category
  • #36134 defect py26-mapnik @0.7.1_6+cairo+gdal+postgis+sqlite: build failure
Last edited 10 years ago by petrrr (previous) (diff)

comment:8 Changed 10 years ago by petrrr

Cc: dbsgeo@… added

comment:9 Changed 10 years ago by petrrr

I CC also the maintainer of py26-mapnik.

comment:10 Changed 10 years ago by dbsgeo@…

I am the previous maintainer but I no longer use Macports and so I would recommend removing py26-mapnik to prevent confusion.

comment:11 Changed 10 years ago by dbsgeo@…

I'll add: I am an active maintainer of the Mapnik project upstream, and any questions about Mapnik are appropriate at https://github.com/mapnik/mapnik/issues.

comment:12 Changed 10 years ago by petrrr

Okay, port py26-mapnik should be discontinues. However currently mapnik does not build due to #45944. This will be resolved with mapnik 3.0. So waiting until this is fixed to have a cleaner upgrade path.

comment:13 in reply to:  1 Changed 10 years ago by ryandesign (Ryan Carsten Schmidt)

Resolution: fixed
Status: newclosed

Replying to stromnov@…:

Yes, I think that py26-mapnik should be replaced by mapnik.

Done in r135506.

Note: See TracTickets for help on using tickets.