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.

[dandv]

As for

when you use a script to install a software you aren't guaranteed to unininstall it in a clean way

With Meteor, you just delete the .meteor folder and /usr/local/bin/meteor. Nothing else is installed.

So @grigio, none of these objections actually apply to Meteor?

[zimme]

@dandv I guess the objections apply as the devs most likely don't know where meteor is installed, they assume installs by scripts are hard to remove, with npm they know it's not the case.

[zimme]

@dandv any thoughts on the meteor-publish idea, if you guys don't think it's a good idea I'll just stop the work as it won't be used.

[grigio]

@zimme yes, but then it needs the superpowers to symlink to /usr/local/bin/meteor @dandv I know for meteor, but in general when you run a .sh anything could happen and often an easy uninstallation isn't provided. In .meteor/release you can change the meteor version per project, not the NodeJS version

[dandv]

@zimme: if you can extract out the meteor publish code and just make an npm out of it, that would be awesome! We could relegate testing to Travis - nobody cares what gets installed on a Travis virtual box.

[zimme]

Great, I'll put some time into this and as soon as I have something useful I'll push it to MeteorPackaging in it's own repo

[splendido]

+1 fot the meteor-publish npm package!

[marcodejongh]

@zimme Hows the splitting up going? Im currently too busy finishing a sprint but I have reserved time next week to work on a travis script for automatically publishing

[zimme]

@marcodejongh Sry, haven't had the time yet. A lot of stuff to finish up at home and I'm also looking for some new work which have a higher priority.

Anyway what I was going to start with was try and use this function as-is and export that. Hopefully we could use it like this.

var publish = require('meteor-publish');

options = {
  create: true
};

publish(options);

We would probably have to include everything it depends on too in the package.

[dandv]

It's been more than a week now since I've started this madness and I was thinking - what if we just have a "meteor build" machine that watches GitHub repos for pushes, merges in anything, runs the test script, and if it still passes, runs meteor publish? I'm happy to sponsor a machine like that, and original library authors don't even need to be bothered.

When we want a library to provide Meteor packaging, we follow the same procedure with forking and submitting the PR, and tell the author that there's nothing they have to do beyond accepting the pull request. Builds will run automatically.

Any services that watch over GitHub repositories, beyond Travis? WebHooks?

[splendido]

That would be awesome! ...do you see it like a free service everyone can hook into by simply adding meteorbuilder among the maintainer of his packages and registering somewhere to put them on the watched list?

also I guess you ment it should watch for new tags/releases and not all new commits ;-)

[marcodejongh]

@dandv I also had that idea originally. But I figured it would be a hassle getting/maintaining the build machine. So just adding it to travis deploy avoids that hassle.

If you do get a build machine easiest approach would probably be making a git user that watches all the repos you automatically want to build. After which you can just poll the github api for changes.

Only problem I see with this approach is that some maintainers aren't that strict with git guidelines, some have broken master branches and may not bother pushing releases to tags.

[mitar]

I am OK with sh, but some more documentation would be probably useful, on the page where sh pattern is proposed to install. When using a known package manager you know how it operates, but when you see sh script you do not and have a feeling that it will do anything. So explaining there and then that it will just do an local install thing and one global symlink would be good.

[zimme]

So I've looked into trying to extract the publishing parts from meteor into it's own package and it turns out it's much more complicated than I first thought, at least for me.