mrt command not working in ubuntu 13.04

[rajanand02]

i installed meteorite with command "sudo -H npm install -g meteorite", installation completed without any issues but mrt command is not working and it is not showing anything..i have node and nodejs installed in my system...i tried the same with ubuntu 12.04 there it works fine and i could even install packages using "mrt add" command...

[mitar]

What is the error you are getting? What does it mean it "is not working"? Can you list what versions of node and other relevant programs you have installed?

[aaronkurtz]

I'm guessing he had the same problem I did.

mrt looks for the command node

!/usr/bin/env node

but Ubuntu's moved the nodejs binary to nodejs

In ubuntu 13.04, node can be provided by the package 'node', which is actually a program for hamradio, or by the package 'nodejs-legacy', which basically creates a symlink from node to nodejs. Fix is to uninstall the ham radio package and go for the legacy one.

this will also show up as /usr/bin/env: node: No such file or directory if someone's just installed nodejs.

Long term, mrt might want to look for nodejs instead of node.

Versions are: nodejs 0.10.15~dfsg as installed on ubuntu 13.04 meteorite@0.6.16 as installed through npm

[mitar]

Ah, I will repeat here again. I really advise against mixing system installed node with Meteor node. This is a very bad advice. Meteor when you install it already bundles and provides node itself. You do not need to install anything system wide. You just get issues if you do.

After installing Meteor, you should add something like the following to your .bash_profile or similar:

export PATH=~/.meteor/tools/latest/bin:$PATH

This will make node and npm provided by Meteor be used when you install Meteorite with npm install.

Positive side effects are:

• you do not need sudo anymore anywhere, Meteor is installed in your home directory, so also installing node packages works without sudo
• Meteor smart packages containing binary/native npm packages work, otherwise they are compiled with system node which is often different version than Meteor node, and then when Meteor node tries to load them it fails with strange errors (for beginners - it says library not found despite obviously being there - just compiled with wrong node version)

[tmeasday]

@aaronkurtz - Any idea how to do this? You'll see mrt.js is just an executable with a #!/usr/bin/env node hashbang.

[mitar]

mrt could be shell script which execs whatever is necessary.

[tmeasday]

@mitar - this isn't exactly right.

Meteorite is just a script that wraps around Meteor. The fact that it's written in node is just a "coincidence" (I've considered re-writing it in ruby or python a bunch of times actually, node is terrible for this kind of programming).

When mrt installs a smart package, it doesn't do anything towards installing the npm depedencies of the package. They'll be installed when mrt eventually shells out to meteor, which as you said, has it's own bundled node version. So the version of node that mrt runs against doesn't affect the version that packages are loaded against.

If you've seen different behaviour it sounds like a bug that's worth following up.

You may be right about avoiding sudo problems (I've never tried doing it your way), although just installing with -H also avoids such issues.

[tmeasday]

@mitar - yes, it is -- you'll see in package.json that it calls out to bin/mrt.js, which, as I said, is a node script.

I'm not sure how you are supposed to be able to realise that node is not actually node and that nodejs is it. Is there a standard way that people get around this problem?

[mitar]

I am saying that mrt could be a shell script which then run correct node executable on mrt.js, bypassing hashbang. And I think it could be easy: if there is nodejs on the system, use that, if not, use node. At least something of that should be installed on the system if user followed instructions.

[mitar]

Yes, it is not an issue of Meteorite itself that native packages are compiled wrong, but it is a consequence of having system node in the PATH. Because Meteor calls node-gyp which is then system node and not Meteor node. Maybe this could be a bug report against Meteor to modify PATH for all subcommands it runs to prefer Meteor bundled node.

One more reason why is good to use Meteor's node to install Meteorite is that then it is available from Meteor to require.

So what I am saying is that instead of recommending people to install system node to use Meteorite, they could simply use bundled Meteor's one. And then you would not have issues with nodejs vs. node.

[tmeasday]

Oh, I get it. Interesting. I didn't know that.

I think you should open a bug against Meteor definitely. It's hardly a safe bet to rely on people not having a system node installed on their machines.

On the subject of encouraging people to use Meteor's built in node rather than a system one for Meteorite---modulo that issue---it's interesting. I'll have to think about it a bit more.

[mitar]

Yes, not many smart packages have binary components. In @PeerLibrary we are using few of them (node-canvas, for example) so we experiences this. That's why we then have this in our README.

[tmeasday]

I think the standard answer to the nodejs vs node problem is to tell people to install nodejs-legacy. Not exactly satisfying but for instance I guess if you are planning on using any other node executables you are likely to run into this issue (for instance I took a look at grunt and it appears it'll have the same issue).

I guess @mitar's installation solution solves this, but I guess my instinct is that it's difficult to tell beginners that they need to modify their $PATH --- it's difficult to give clean, easy to follow instructions that work across OSes. Hrmmm...

[mitar]

Again, if mrt command is just a bash script, then it can configure PATH to Meteor's node for the user.

[mitar]

(But then Meteor's node will probably not find Meteorite which was installed system-wide. Oh joy. :-) )

[tmeasday]

That sounds a bit scary!

[mizzao]

@tmeasday has Meteor been in touch with you about the eventual integration of Meteorite into Meteor? I'm sure this issue will be wrapped up along with that.

[tmeasday]

Yes, it'll be wrapped up by version 1.0

[stacksize]

I had the same problem on Ubuntu 14.04, fixed it by following the instructions on this page:

https://groups.google.com/d/msg/meteor-talk/h-K0etuaOU0/IqgWf8HEsEIJ

Go to the /usr/bin folder and do this:

sudo ln -s nodejs node

That's it, works great afterwards.

[paralin]

@alexivanovs You should be using the core meteor packaging system now though. mrt is entirely deprecated.

[stacksize]

@paralin that's interesting, I was following the instructions on this page:

https://github.com/SachaG/Void

and I didn't realize that, can you give me a tutorial/news update on that particular change?

(ahh, I guess you mean that things are now directly managed through Atmosphere packages?)

[paralin]

You should not use that if you're just getting started with Meteor. There have been some very significant changes and improvements between then and the release of Meteor 1.0.

Now you add packages like so:

meteor add author:package

For example

meteor add iron:router

Packages are fetched from http://atmospherejs.com

Please read the documentation on http://meteor.com

On Thu Dec 04 2014 at 9:29:30 AM Alex Ivanovs notifications@github.com wrote:

@paralin https://github.com/paralin that's interesting, I was following the instructions on this page:

https://github.com/SachaG/Void

and I didn't realize that, can you give me a tutorial/news update on that particular change?

Reply to this email directly or view it on GitHub https://github.com/oortcloud/meteorite/issues/203#issuecomment-65669174.

[stacksize]

Yes, that's what I thought.

Sure, I'm just getting through the meteortips.com free book, and will soon get a copy of Discover Meteor.

Thanks, Christian.

[mitar]

You still cannot run packages from git checkout without mrt. Or Meteor fork.

[stacksize]

@mitar can you elaborate please?

[mitar]

Meteor by itself does not provide a way that you depend your project on a git version directly. Like this.

[mizzao]

I accomplish a similar thing to @mitar by using a meta repo and then local symlinks.

[mitar]

Not to forget that I am also using Meteor fork. There is still no easy way to deploy nicely to fellow developers on a project without Meteorite.

And you do not want to publish a new version just so that your fellow developers can checkout a new version of your project.

[tmeasday]

Another option is to use git submodules rather than mrt. Not that mrt doesn't work but for a simple git dependency it might be simpler to not involve it. Of course @mitar is correct at gitted version of Meteor (thankfully there aren't too many reasons to do that any more, unless you are modifying the commandline tools).

[mitar]

But there are still many things MDG does now want to include into the Meteor.

[stacksize]

Thanks guys, glad to have kickstarted that discussion!