4 ms·

I am to blame for that. Here is our thinking on it: - Though it "feels wrong" (definitely with you there), is it really any different from downloading an insta

I am to blame for that. Here is our thinking on it: - 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 :)

collinjackson 15y ago
How about making it https://install.meteor.com https://install.meteor.com?
moe 15y ago
I'm chiming in here because it may still be early enough to stop you. 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").
- mhansen 15y ago
  It would be more helpful for people reading this comment if you gave reasons beyond "It's taboo". I'm sure you have good reasons, I just can't see them here.
  - moe 15y ago
    Portability, robustness, flexibility and security. There's little reason to spread out a package like meteor all over /usr/local. But many reasons against doing that. 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?
    - haberman 15y ago
      Couldn't agree more. It's like using a library that insist on putting everything in global variables.
    - Vekz 15y ago
      I totally agree with this. This is a lesson that NPM already had to learn the hard way.
    - mrothe 15y ago
      I am definitely not in favour of piping curl output to sh and giving root access. 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.
    - geoffschmidt 15y ago
      I agree with all of this :) Meteor is self-contained and installing it in /usr/local is totally optional. The reason we install into /usr/local is that it is a way to get the 'meteor' command into the user's path without trying to edit their dotfiles for them, and without setting obscure system preferences that the user would have trouble unsetting. We went to a lot of trouble to make it easy to try Meteor, and we thought that "great, now go edit your dotfiles" would have lost a lot of people. 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.
cdmoyer 15y ago
I will admit that it's my preferred way to install things like this. I can look at it and see what will happen easily. 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" This probably needs to check it $PARENT/bin is actually in the path, and maybe tell the user that they'll need to add it.
stuffihavemade 15y ago
Please provide an npm package! In addition to the security, uninstall and versioning problems mentioned by others, not every one runs Debian and Redhat. If you provide a node package, anyone who can install node can install meteor. edit: Any by not every one, I mean me, running ArchLinux.
- hk_kh 15y ago
  Here http://news.ycombinator.com/item?id=3828160 http://news.ycombinator.com/item?id=3828160 a modified version of the installer compatible with arch. npm is out of my scope (in fact, even arch is)
  - deleted 15y ago
    [deleted]

collinjackson 15y ago

How about making it https://install.meteor.com https://install.meteor.com?

moe 15y ago

I'm chiming in here because it may still be early enough to stop you. 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").

mhansen 15y ago
It would be more helpful for people reading this comment if you gave reasons beyond "It's taboo". I'm sure you have good reasons, I just can't see them here.
- moe 15y ago
  Portability, robustness, flexibility and security. There's little reason to spread out a package like meteor all over /usr/local. But many reasons against doing that. 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?
  - haberman 15y ago
    Couldn't agree more. It's like using a library that insist on putting everything in global variables.
  - Vekz 15y ago
    I totally agree with this. This is a lesson that NPM already had to learn the hard way.
  - mrothe 15y ago
    I am definitely not in favour of piping curl output to sh and giving root access. 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.
  - geoffschmidt 15y ago
    I agree with all of this :) Meteor is self-contained and installing it in /usr/local is totally optional. The reason we install into /usr/local is that it is a way to get the 'meteor' command into the user's path without trying to edit their dotfiles for them, and without setting obscure system preferences that the user would have trouble unsetting. We went to a lot of trouble to make it easy to try Meteor, and we thought that "great, now go edit your dotfiles" would have lost a lot of people. 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.

cdmoyer 15y ago

I will admit that it's my preferred way to install things like this. I can look at it and see what will happen easily. 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" This probably needs to check it $PARENT/bin is actually in the path, and maybe tell the user that they'll need to add it.

stuffihavemade 15y ago

Please provide an npm package! In addition to the security, uninstall and versioning problems mentioned by others, not every one runs Debian and Redhat. If you provide a node package, anyone who can install node can install meteor. edit: Any by not every one, I mean me, running ArchLinux.

hk_kh 15y ago
Here http://news.ycombinator.com/item?id=3828160 http://news.ycombinator.com/item?id=3828160 a modified version of the installer compatible with arch. npm is out of my scope (in fact, even arch is)
- deleted 15y ago
  [deleted]