Why are library authors put off by .sh files?

[dandv]

About half the library maintainers I've approached to integrate official support for Meteor packaging, have had a pretty negative reaction to it.

That was caused primarily by Meteor's canonical way of installing itself by curl-ing a shell script and executing that. There has also been opposition to .sh scripts used to automate testing and publishing.

Examples include the Moment.js, Isotope and d3 developers.

I'm curious, why is there this aversion against .sh scripts?

Whether you curl https://install.meteor.com | sh or run npm install meteor (assuming there was one, #21), you still trust the Meteor code not to perform malicious actions. But which is easier to inspect, a 50-line shell script (half of which is comments), or a binary pulled by npm/aptitude/yum/etc. and stored somewhere on your filesystem?

[desandro]

1. Because it clutters up your project. My libraries are precious things. I want them to be as elegant as possible.
2. The publishing code should be generalized as a CLI. It doesn't belong as part of the library
3. Other package managers like npm and Bower only require one manifest.json file.
4. As an author, I don't have much interest in the inner workings of how publishing to your platform works

[grigio]

Some other problems of curl https://install.meteor.com | sh

• it you are on Linux / OSX it requires root priviledges (npm install doesn't)
• it alwais installs latest version of meteor (you can't choose)
• when you use a script to install a software you aren't guaranteed to unininstall it in a clean way

[dandv]

@grigio: good points. I hope the efforts to provide an up-to-date meteor npm package are revived.

[grigio]

@dandv I've seen it, but I don't think it will be fixed soon. MeteorJS doesn't work with nodejs:latest and it also isn't tested with mongodb:latest so the "bundle everything" way it's a compromise

[marcodejongh]

Maybe it's an idea to just make a travis-ci template like https://github.com/arunoda/travis-ci-meteor-packages that publishes the package.

We could have whatever script we use on travis look for a manifest file that defines what the meteor package should look like.

Then the only problem causing resistance then, would be that the publishing would be triggered on travis and not via a cli tool. But it would eliminate the need for most of the extra files in the library's repo. It would just add 2 or 3 extra lines in the .travis.yml instead.

Would that take away some of your concerns @desandro ?

[gadicc]

It's a cool idea but I'm not sure we'd have any way to authenticate the publisher?

I guess we could make our own website that uses meteor accounts, and packages and publishes every time there's a release made on github. If authors aren't already using release tags, I could guess this would be met with less resistance. (And as before, signup for meteor account and add repo on a website, once off).

[marcodejongh]

@gadicc Authentication is pretty easy I've already done this for continuous deployment to meteor.com: https://github.com/gfk-ba/meteor-continuous-deployment

Travis allows you to store encrypted env variables so your secrets are safe.
And you can use a expect script for automating the use of the meteor cli tool.

[gadicc]

Oh, I guess I should take some more time discovering travis properly :> That's awesome! Very interested to hear what library authors think of this approach. And also, it looks like you're all set to take this on? :) Either way, that's some awesome work... hadn't run into it until now.

[marcodejongh]

Sure I can set something up later today using the moment integration as a example

[dandv]

The best integration at the... moment, would be the Hammer.js one.

[dandv]

Just noticed that [the official instructions for installing Node also involve curl ... | sudo bash -](curl -sL https://deb.nodesource.com/setup | sudo bash -). Worse - sudo bash.

[zimme]

I'm looking into a way of isolating the meteor publish/publish-for-arch into a separate meteor-publish node package...

This way lib authors can use this package in both grunt and gulp to publish meteor packages without the need for meteor. If they don't have to install the entire platform maybe some are more willing to yield.

What do you guys think of this idea?

[zimme]

• if you are on Linux / OSX it requires root priviledges (npm install doesn't)

This isn't true, meteor installs in the users home dir under .meteor

[dandv]

@grigio:

it alwais installs latest version of meteor (you can't choose)

Also, you can specify what release you want on a per-project basis, in the .meteor/release file.