Version of bones in TileMill

RossGammon commented 10 years ago

Hi, I am writing on behalf of the Debian GIS team who would like to package Tile Mill for Debian. Currently, the version of node-bones in Debian is 2.0.1 (http://packages.qa.debian.org/n/node-bones.html). TillMill seems to need 1.3.27 which is actually newer than the version in Debian. With 2.0.1, this is the result: anarcat@marcos:tilemill*$ sudo su -s /bin/sh -c 'HOME=/usr/share/mapbox NODEPATH=/usr/lib/nodejs:/usr/share/tilemill /usr/bin/nodejs /usr/share/tilemill/index.js --config=/etc/tilemill/tilemill.config' mapbox [tilemill] Note: Unknown option "server" in config file. [tilemill] Note: Unknown option "server" in config file. [tilemill] Plugin [carto] loaded. [tilemill] Plugin [editor] loaded. [tilemill] Plugin [fonts] loaded. [tilemill] Plugin [templates] loaded. [tilemill] [tilemill] TypeError: Cannot call method 'error' of undefined [tilemill] at server.initialize (/usr/share/tilemill/servers/OAuth.bones:45:10) [tilemill] at Server (/usr/lib/nodejs/bones/server/server.js:10:10) [tilemill] at new child (/usr/share/javascript/backbone/backbone.js:1392:34) [tilemill] at servers.Core.initialize (/usr/share/tilemill/servers/Core.bones:16:14) [tilemill] at Server (/usr/lib/nodejs/bones/server/server.js:10:10) [tilemill] at new child (/usr/share/javascript/backbone/backbone.js:1392:34) [tilemill] at command.initialize (/usr/share/tilemill/commands/core.bones:224:28) [tilemill] at null. (/usr/lib/nodejs/bones/server/command.js:8:14) [tilemill] at command.bootstrap (/usr/share/tilemill/commands/core.bones:219:5) [tilemill] at Command (/usr/lib/nodejs/bones/server/command.js:7:10) [tilemill] Error: child process: "core" failed with code "8" [tilemill] Error: child process: "tile" failed with code "143" [tilemill] Closing child process: core (pid:7988) [tilemill] Closing child process: tile (pid:7990) Exiting [tilemill]

Before we consider trying to package the 1.3.x series of node-bones instead, are there any plans to switch TIleMill to the 2.x.x series?

For information, the relevant Debian bug (against node-bones) is: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=743152

Regards,

Ross Gammon

springmeyer commented 10 years ago

Hi @RossGammon - thanks for getting in touch and thanks for your initiative to package TileMill.

To avoid this problem I would recommend that debian packaging of TileMill not package bones separately. Simply accept the npm/node.js convention of dependencies being installed locally and each package getting is own copy and necessary versions. Meaning that node_modules/bones should be included in the .deb for TileMill and an external bones should not be needed. TileMill is fundamentally designed around this approach: to depend on packages installed locally in node_modules. The only exception to this rule is node C++ modules like node-mapnik, which, due to the dependency on libmapnik.so, do make sense to package globally in apt.

To answer your question specifically:

are there any plans to switch TIleMill to the 2.x.x series?

No. Because Bones is not being actively developed. In the near future upcoming TileMill releases will drop the bones dependency completely. This is the reason I have been maintaining a bones 1.3.x branch specifically for TileMill 0.10.x series: because it will be dropped eventually it is not worth the effort to try to upgrade to Bones 2.x.

RossGammon commented 10 years ago

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

On 03/31/2014 10:52 PM, Dane Springmeyer wrote:

Hi @RossGammon https://github.com/RossGammon - thanks for getting in touch and thanks for your initiative to package TileMill.

To avoid this problem I would recommend that debian packaging of TileMill not package |bones| separately. Simply accept the npm/node.js convention of dependencies being installed locally and each package getting is own copy and necessary versions. Meaning that |node_modules/bones| should be included in the .deb for TileMill and an external |bones| should not be needed. TileMill is fundamentally designed around this approach: to depend on packages installed locally in |node_modules|. The only exception to this rule is node C++ modules like node-mapnik, which, due to the dependency on libmapnik.so, do make sense to package globally in apt.

To answer your question specifically:

are there any plans to switch TIleMill to the 2.x.x series?

No. Because Bones is not being actively developed. In the near future upcoming TileMill releases will drop the bones dependency completely. This is the reason I have been maintaining a bones 1.3.x branch specifically for TileMill 0.10.x series: because it will be dropped eventually it is not worth the effort to try to upgrade to Bones 2.x.

— Reply to this email directly or view it on GitHub https://github.com/mapbox/tilemill/issues/2260#issuecomment-39140231.

Thanks for the quick response Dane. It is the Debian policy not to include bundled dependencies because it needlessly increases the size of the archive when the same code is packaged numerous times. We will take your advice onboard. Keep up the good work. Regards, Ross

-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJTOdqSAAoJEFP+e72miRD8AeAP/i/5MM9eNHaeat3vs/De4EYD im3DQiKewXjgHiYkrCAAFFkPz/QqxwZPeLW8GAJRhNLfAaf5Z/l55IqBwQL85QIH BmnzFfq3MMQDgBmj3oAgOdruCNRjSk3BYsHHH/WFwprzNu173Fhmw3I3IHAh0Rnx 2BOj1Xxn9MsNc4rTAJddAAVJyCcLS9yPU95fbVw58km5JCRP1bpVea9L0AusMkT+ UJP2f1yLZapyEF+qwhsN9TIgpakzhgxZqcaIiuA1U6WYiXVn58C1pUynnlm8HqR2 hhzxjXkOTb/KWGn0k7bUzdH2RPDLeL+rwmIuYmzWt/yGPmAtSt+66ksrQPN62HJb 01drE0emmLcnJgYU4goHDcF/oA8ZyaIx1i8NX/ei1Safc6/5EoOGK4TFm2uvnq57 85RoLWGgcw0vNF5LBw6fphCwan5SYcZUeMtrlyJYSUrn1H/OorsIZPMdQ7KwuP0i Qqk6fdzS+ibbH2NlkI5fVg52c11zrccVTCCdGn9q9rhlvQl8JCOnRqyRaA/sNrUk +ok11t6WF7AZd6BdE5smbtMXUeliqwf8CpnWGDf16nhzek4ID/DcC8KGLof333Un o1lkItX0VwLJmqXN1ioONu5PSMNB3pacTQ0ogUrq375M3nXebmq/EaYzCEdaI7Th 01qddBKcTvjJPJztqNN4 =ERWW -----END PGP SIGNATURE-----

springmeyer commented 10 years ago

It is the Debian policy not to include bundled dependencies because it needlessly increases the size of the archive when the same code is packaged numerous times.

Yes, I am aware of the policy and the benefits. And I support this policy in the majority of cases. I'll clarify: I'm not recommending that you go against the policy but rather to approach TileMill with different eyes. Consider the pure JS modules that TileMill declares in package.json as part of the core application and not external dependencies, except in rare cases like C++ modules. This would make it vastly easier for you to package TileMill and it would avoid major challenges and potential bugs you might create by using different versions and different packaging methods that we, as core TileMill developers, have tested.

We will take your advice onboard.

Thank you. I would therefore recommend actually removing bones from the package debian repository completely.

springmeyer commented 10 years ago

@RossGammon - so how it is going? What are you thinking here?

springmeyer commented 10 years ago

/cc @kapouer for advice too (as the packager of mapnik/node-mapnik)

kapouer commented 10 years ago

@RossGammon this is policy 4.13 and it uses words that are less strict about copies of other software. Ultimately the best solution is in the hands of the packager, provided it is justified. I propose we include legacy bones and explain clearly in debian/copyright (and debian/patches) why we are doing this:

node-bones has not been active for at least two years (only a few commits) - and that's not because it's super-stable :)
tilemill will never upgrade its version to latest bones, is maintaining its own version for maintenance, and won't develop new software using it It's actually a good thing to not package node-bones for debian !

RossGammon commented 10 years ago

On 04/03/2014 09:20 PM, Jérémy Lal wrote:

@RossGammon https://github.com/RossGammon this is policy 4.13 https://www.debian.org/doc/debian-policy/ch-source.html#s-embeddedfiles and it uses words that are less strict about copies of other software. Ultimately the best solution is in the hands of the packager, provided it is justified. I propose we include legacy bones and explain clearly in debian/copyright (and debian/patches) why we are doing this:

node-bones has not been active for at least two years (only a few commits) - and that's not because it's super-stable :)

tilemill will never upgrade its version to latest bones, is maintaining its own version for maintenance, and won't develop new software using it It's actually a good thing to /not/ package node-bones for debian !

— Reply to this email directly or view it on GitHub https://github.com/mapbox/tilemill/issues/2260#issuecomment-39493364.

cc-ing Antione who has also been working on Tilemill.

Sorry - I have been distracted by a few other things this week.

Yes, I had come to the same conclusion that it would be better to keep the included version of bones in this case. I will do that hopefully today.

But even with the embedded bones, Antione had identified a few other problems (listed on the WNPP bug) that I haven't had a chance to dig into.

Hopefully I will get a chance to look at this today as well. Thanks all for your help!

Ross

Komzpa commented 7 years ago

@RossGammon hi! is there any progress packaging Tilemill for Debian?

RossGammon commented 7 years ago

I wasn't able to get the last release working (dependency issues I think), and as the project had seemed to be stalled, I put my efforts elsewhere. But I will be happy to come back to it after a new release is made. There are a lot of Debian users & contributors that would like to see TIleMill in Debian!

toton6868 commented 7 years ago

@Komzpa, @RossGammon and @springmeyer

I (with the extensive help of my boss) have successfully installed Tilemill on Debian 9. We build it from source. We faced few problems when installing Mapnik. Few workaround in few files before Make help us a lot. As we do not have GUI access to server we tried it as Service and make it available to remote users. We have changed the port and used 8000 and 8080 ports instead. So the Service started as

./index.js --server=true --listenHost=0.0.0.0 --coreUrl=${TILEMILL_HOST}:8000 --tileUrl=${TILEMILL_HOST}:8080

But We are now facing few problem. Tilemill is opening but no default project is opening their layers. Then we have tested by opening new project and added a sample Shapefile. Its not opening and Saying

Unable to reach the local TileMill Server. Check the logs for details. If this problem persists please contact support at: http://support.mapbox.com/discussions/tilemill

Any idea why it is happening?

tilemill-project / tilemill

Version of bones in TileMill #2260