This is a very uncool way to install something:
$ curl install.meteor.com | /bin/sh $ curl install.meteor.com | /bin/sh- Though it "feels wrong" (definitely with you there), is it really any different from downloading an installer package and running it?
- You can just go to install.meteor.com in your browser if you want to see what the script does (or just leave off the | sh), which is arguably better than other installation mechanisms.
Curious to hear people's thoughts :)
Do. Not. Require. Root. Not optionally, not sometimes, not "maybe". NEVER.
Your universe is ~/.meteor. Do not even think about touching anything outside that. It's taboo.
You clearly know what you're doing otherwise, so please get this one right from the start and save yourselves a lot of headache later on (cf. npm).
Install to ~/.meteor and provide the user with a small snippet to paste to their ~/.bash_profile ("source ~/.meteor/magic.sh").
I'm sure you have good reasons, I just can't see them here.
To illustrate, a few simple questions:
What if I need multiple meteor versions on the same system (different versions for different users/projects)?
How do I quickly switch between different meteor versions (often needed in fast-moving projects like this)?
How do I monkey-patch meteor to try something out and/or contribute back?
What if I absolutely must mix meteor with an unsupported version of node or other runtime dependency?
What if all my servers are SuSE Solaris95 but you only provide packages for Debian and RedHat?
How do I bundle my meteor runtime with my deployment?
I do prefer packages installed to /usr. You can easily solve the multiple-version-problem: Debian/Ubuntu has `alternatives`; Gentoo has `eselect` etc.
With these tools it is easy to "slot" packages (Gentoo terminology): /usr/bin/meteor would become a link to /usr/bin/meteor-0.1, /usr/bin/meteor-0.2 or whatever. And it is selected by the `alternatives`/`eselect` commands.
And how do you bundle your runtime? Just install the darn package!
If you are using SuSE Solaris95 and all your software is packaged for Debian or RedHat, then you should consider switching to a distribution that makes it easy to install third party software using the native package manager. If that means building a deb or rpm, then so be it; it's not that difficult.
If you don't want it in /usr/local, you can check it out anywhere you like and just run the 'meteor' in the top directory of the checkout, and it'll work great. This is mentioned in the README/on Github, and it's how we have been developing Meteor. You can have as many copies of Meteor on your system as you like, and they can even coexist with a copy at /usr/local. So for me, I type '~/co/meteor' to run the meteor that I'm developing on, and 'meteor' by itself to run the latest official release.
You can either build the binary dependencies (node, etc) yourself by running an included script, or if you do not, the first time you run meteor it will automatically fetch a prebuilt binary kit for your convenience. All of the binary dependencies are kept in a directory in the checkout and managed by meteor, meaning that each meteor install on your system can have its own version of node.
Finally, to your last point, 'meteor bundle' does exactly that :P In fact, right now on our deploy servers, we have live apps running that were deployed with a variety of historical versions of meteor, all coexisting side by side.
I'm sure we'll have to revisit all of this as the Meteor ecosystem gets bigger and more complicated -- when all of the packages do not fit in a 'packages' directory, and when there are more binary dependencies than node and mongo. But I hope that this helps to persuade you that we're not totally nuts, despite how sleep deprived I was when we recorded that screencast.
If you thought this was a helpful answer, could you repost the question on Stack Overflow (with the 'meteor' tag), and drop me an email (address is in my HN profile?) That way I could repost this answer there in case it might be helpful to other people.
I agree with almost everything you say; you seem to have it right then, I just didn't go through github so I never saw the README.
However, I would still argue that you should get rid of the packages, that's extra-work you could better spend elsewhere. For someone installing a dev-toolkit it's absolutely not too much asked to paste "echo >>~/.bash_profile 'source ~/.meteor/magic.sh'".
They have to do that anyway as soon as they need the latest git-HEAD because of some bug in the release version (we know how it goes, don't we? ;-)).
So by giving them the right instructions right away you save them this extra step. And you save yourself from making a bad (and false!) first impression on the older and grumpier devs like myself.
I will also admit to disagreeing with the poster suggesting that it should all go to ~/.meteor. I kind of hate that type of install... at least when I don't have an option. I don't want to install it multiple times for different users, and I don't like "system" software in my home directory, I like to keep my user data there and back it up more regularly that /usr/local which is all things I can reinstall in case of disaster.
I guess the ideal would be to ask the user.
Comment...
# add to $PATH
mkdir -p "$PARENT/bin"
rm -f "$PARENT/bin/meteor"
ln -s "$TARGET/bin/meteor" "$PARENT/bin/meteor"
edit: Any by not every one, I mean me, running ArchLinux.
npm is out of my scope (in fact, even arch is)
As someone else pointed out, it also makes versioning difficult.