Opened 13 years ago
Closed 10 years ago
#30187 closed submission (wontfix)
py27-mapnik 0.7.1 Support python 2.7 for Mapnik
| Reported by: | jon.tirsen@… | Owned by: | petrrr |
|---|---|---|---|
| Priority: | Normal | Milestone: | |
| Component: | ports | Version: | 1.9.2 |
| Keywords: | Cc: | dbsgeo@…, ryandesign (Ryan Carsten Schmidt), cooljeanius (Eric Gallager) | |
| Port: | py26-mapnik, py27-mapnik |
Description
Attachments (2)
Change History (13)
Changed 13 years ago by jon.tirsen@…
Changed 13 years ago by jon.tirsen@…
| Attachment: | patch-boost-filesystem3.diff added |
|---|
comment:1 follow-up: 3 Changed 13 years ago by ryandesign (Ryan Carsten Schmidt)
| Cc: | dbsgeo@… ryandesign@… added |
|---|---|
| Port: | py26-mapnik py27-mapnik added |
comment:2 Changed 13 years ago by jon.tirsen@…
Maybe the simplest solution is to have just a mapnik port which has two options +python26 and +python27? There's no _simple_ way to install mapnik for two different python versions. (It's possible but would require a lot more work.)
comment:3 Changed 13 years ago by dbsgeo@…
Replying to ryandesign@…:
This new py27-mapnik port installs tons of files that conflict with the existing py26-mapnik port, which is not how py* ports are supposed to behave; they're supposed to be simultaneously installable.
I'm rather confused why the existing port is called py26-mapnik at all. Why isn't it just called mapnik?
because mapnik's python binding are written in C++ (using boost python) and only one version of boost python (per python version) can be installed (at least that is what I though back when the port was submitted). Ideally their should be a libmapnik pure C++ port and a python-mapnik (just the bindings) port.
We could then discuss whether it should have variants allowing the user to choose the desired python version. The problem with doing so is that it depends on boost having been installed with the corresponding python variant.
having boost python be a separate port (or a separate port per python version) would begin to solve this perhaps.
And of course only one variant of a given port can be active at once. But mapnik is not the only software that uses boost's python features. Therefore all ports using boost's python features must simultaneously be updated to have such python variants. Or we could just decide to update all such ports from python26 to python27 and not give the user a choice.
btw, I no longer use macports because I found it way easier to install boost (just the bits mapnik needs) and I know provide binaries for users: http://dbsgeo.com/downloads/#mapnik-0.7.1. So, trying to help here but I'm not an active macports users to not going to be of much help.
comment:6 Changed 10 years ago by petrrr
There is a mapnik port @2.2.0 now. So this ticket can probably be closed. And maybe py26-mapnik should be deprecated.
comment:8 Changed 10 years ago by petrrr
| Cc: | Peter.Danecek@… removed |
|---|---|
| Owner: | changed from macports-tickets@… to petr@… |
| Status: | new → assigned |
Can we close this ticket as wontfix? Any objections?
comment:10 Changed 10 years ago by bpanulla (Brian Panulla)
Seems to have been overcome by events. I'm okay with closing it.
comment:11 Changed 10 years ago by petrrr
| Resolution: | → wontfix |
|---|---|
| Status: | assigned → closed |
This new py27-mapnik port installs tons of files that conflict with the existing py26-mapnik port, which is not how py* ports are supposed to behave; they're supposed to be simultaneously installable.
I'm rather confused why the existing port is called py26-mapnik at all. Why isn't it just called mapnik?
We could then discuss whether it should have variants allowing the user to choose the desired python version. The problem with doing so is that it depends on boost having been installed with the corresponding python variant. And of course only one variant of a given port can be active at once. But mapnik is not the only software that uses boost's python features. Therefore all ports using boost's python features must simultaneously be updated to have such python variants. Or we could just decide to update all such ports from python26 to python27 and not give the user a choice.