Publishing the latest version

[smowden]

Hey mate, I saw that you made the changes necessary for the plugin to work under Meteor 0.9.0, however it seems that the latest version available via Atmosphere is 0.6.2. I would appreciate it if you could take the time to publish to the new Meteor package server. In any case thank you for your work on this package.

[Nemo64]

Me neither.

The last solution I can think of is to clone this package into your /packages/ folder (if you name it nemo64:translator it should imminently use that one instead of the downloaded one). At best checkout 7ad8cc7f03bdc4741a3f15f0c848858edb520768 because there I haven't swichted to the cldr package yet. Try if that works.

[tanis2000]

You gave me one more idea actually. I removed the nemo64:translator@0.6.11 and added nemo64:cldr@2.2.1 instead. I run meteor and here's what I think might be the culprit:

W20140911-15:32:28.711(2)? (STDERR)
W20140911-15:32:28.980(2)? (STDERR) /home/tanis/.meteor/packages/meteor-tool/.1.0.28.u858sv++os.linux.x86_64+web.browser+web.cordova/meteor-tool-os.linux.x86_64/dev_bundle/lib/node_modules/fibers/future.js:173
W20140911-15:32:28.981(2)? (STDERR)                         throw(ex);
W20140911-15:32:28.982(2)? (STDERR)                               ^
W20140911-15:32:28.982(2)? (STDERR) Error: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.14' not found (required by /home/tanis/.meteor/packages/nemo64:cldr/.2.2.1.1wbwtzn++os.linux.x86_64+web.browser+web.cordova/npm/node_modules/cldr/node_modules/libxmljs/build/Release/xmljs.node)
W20140911-15:32:28.983(2)? (STDERR)     at Module.load (module.js:356:32)
W20140911-15:32:28.984(2)? (STDERR)     at Function.Module._load (module.js:312:12)
W20140911-15:32:28.984(2)? (STDERR)     at Module.require (module.js:364:17)
W20140911-15:32:28.985(2)? (STDERR)     at require (module.js:380:17)
W20140911-15:32:28.985(2)? (STDERR)     at bindings (/home/tanis/.meteor/packages/nemo64:cldr/.2.2.1.1wbwtzn++os.linux.x86_64+web.browser+web.cordova/npm/node_modules/cldr/node_modules/libxmljs/node_modules/bindings/bindings.js:74:15)
W20140911-15:32:28.985(2)? (STDERR)     at Object.<anonymous> (/home/tanis/.meteor/packages/nemo64:cldr/.2.2.1.1wbwtzn++os.linux.x86_64+web.browser+web.cordova/npm/node_modules/cldr/node_modules/libxmljs/lib/bindings.js:1:99)
W20140911-15:32:28.986(2)? (STDERR)     at Module._compile (module.js:456:26)
W20140911-15:32:28.987(2)? (STDERR)     at Object.Module._extensions..js (module.js:474:10)
W20140911-15:32:28.987(2)? (STDERR)     at Module.load (module.js:356:32)
W20140911-15:32:28.988(2)? (STDERR)     at Function.Module._load (module.js:312:12)
=> Exited with code: 8

Looking at my version of GLIBC I can see that I'm at 2.13 and not at 2.14

tanis@samantha:~/test-translator$ ls -al /lib/x86_64-linux-gnu/libc.so.6
lrwxrwxrwx 1 root root 12 Aug 26 23:10 /lib/x86_64-linux-gnu/libc.so.6 -> libc-2.13.so

Now the question is.. why is it depending on that specific version of GLIBC?

[Nemo64]

Well, I uploaded that package using ubuntu 14.04 and here are the requirements of libxml2 there. On the other hand: here is debian wheezy's libxml2.

Upgrading libc is very dangerous so you shouldn't do it if debian doesn't provide it.

I already considered modifying the node-cldr module so that it doesn't need binaries as all this here is a pain. However, I haven't found a good xml module yet and I don't have that much of a knowledge about node modules but maybe there is no other way.

[tanis2000]

I might republish the nemo64:cldr arch for Linux 64 from my distro and it would link it against 2.13 and solve the issue as it's a lower version and it would work for newer too.

But the problem is more broad as it means that the packaging system, as it is now, is going to cause a lot of problems with different Linux distro.

Dropping binaries is the best I can think of.. as long as it's doable.. but I guess there might be other packages that will end up relying on binaries at some point.

[tanis2000]

BTW cloning both nemo64:translator and nemo64:cldr into my packages folder using those names as their respective folders did the trick as you suggested.

[Nemo64]

I kind of expected that. meteor then graps a copy of the npm package itself and uses the binaries on the system. If it works for you now, great!

But I have some good news. I forked the node-cldr package and created some huge regex replace expression to efficiently replace libxmljs with domxml and xpath. And what can I say, it was way easier than I expected. After some fine tuning I just now got all unit test of that package to pass. (Really satisfying feeling btw :D ). I'll check if the tests of the translator pass if I use it there again but this may solve this problem... for this package at least.

[tanis2000]

@Nemo64 that's good news! I suppose you could release a -rc version of the package so that I can test it as well. Just let me know.

[Nemo64]

I think I stumbled over another problem there. Is there an official way to depend on npm packages that aren't released? I don't think so. I found that the less package does it with a little hack but that didn't work for my fork. I get an error: couldn't run 'npm shrinkwrap'.

The only way I found I can test it with, is to link the cldr node package into the .npm folder of my cldr meteor package but that's only good for minimal testing. Good news: the tests pass. So I made a pull request to see what they there think about it. If that gets accepted I can update the dependency here and the problems should be gone.

[Nemo64]

I released it now. I'm pretty confident that it'll work as nothing really changed except the dependency. There was no annoying "arch" error while publishing so it should run everywhere now.