free public hosting of binaries anyone ?

[albanm]

Maybe this question doesn't belong to the scope of this project, but it is related.

I come from this well known npm issue npm/npm#1891

It was closed as "node-pre-gyp has reached enough feature-completeness".

But it seems to me that node-pre-gyp while looking very good only responds to a part of the original need. What about hosting in the npm registry, is this forgotten ?

Honestly I don't intend to pay for an AWS S3 account to publish a small open source module. And anyway it doesn't seem a very sustainable approach to require every individual maintainers to do this.

So, is there any hope ?

[Mithgol]

I'm the one who opened and closed that issue.

The idea of hosting things in npm registry was forgotten because I was not sure at the moment whether binary packages are welcome in npm registry. (And I am still not sure, to be precise.)

However, I also understand that there should be a way to host small open source binaries for free (without the need to pay for some Amazon S3 service). The most promising of such solutions is probably the uploading of files as binaries attached to GitHub releases using the corresponding GitHub API.

So… there is hope.

But… there is no implementation yet. In node-pre-gyp, I mean; there might be other packages such as github-release for example.

[albanm]

Ok thanks, there is potential in Github releases. I would love a close integration with npm, but node-pre-gyp + github release assets might be the next best thing.

Found this link to post an asset from appveyor : http://stackoverflow.com/questions/25349296/how-to-release-automatically-your-artifact-to-github

And this link for travis-ci: http://docs.travis-ci.com/user/deployment/releases/

Is this a direction that node-pre-gyp might take ? If I find the time I may try something.

[albanm]

Just so you know I have been looking into the code of node-pre-gyp and done a few tests with git releases. I see no great difficulty and I won't hack my way with external scripts and tools, instead I will soon submit a pull request here. I just hope maintainers are opened to supporting alternative storage solutions.

I still don't know if I will make existing commands (publish, unpublish and maybe install) adapt to some parameter or if it will be separate commands (publish-gh, unpublish-gh and install-gh for example).

[springmeyer]

I'm open to reviewing a pull that adds support for github releases, but it will need to be cleanly implemented and be reasonable to maintain. Tall order I know but S3 support is working well and having two publish options adds complexity so its got to be worth it.

I should clarify that node-pre-gyp already supports hosting anywhere you choose - A developer can freely set the host value in the package.json to somewhere other than S3. But I understand you've likely figured this out already and are concerned about making is easy to upload - like the s3 publish support provides. Seems like a single publish command would be the best interface and a setting in the node-pre-gyp config that determines which storage service is used.

[albanm]

Ok. I am willing to make this as clean and as reasonable to maintain as possible.

From what I have seen of the github releases API, even the install command will probably have to be modified as 2 steps are required (get the list of assets to get the id from the tarball name then download from the id).

Plans are getting more clear in my head:

• A 'hosting' parameter that defaults to 's3' for compatibility
• A github parameter that can replace host, with a value looking like that: 'albanm/node-addon-example/releases/v{version}'
• A hosting implicit interface that will have 'post', 'get' and 'del' functions or something similar.
• A hosting-s3 module that centralizes all actual s3 related actions
• A hosting-github for github support
• Modify publish/unpublish/install commands to require dynamically 'hosting-{hosting}' much like you already require the AWS sdk. Determine the right amount of shared logic to make hosting implementations as lightweight as possible.

Once properly made it will even be possible to externalize the hosting implementations. If it goes this far I am willing to maintain the github implementation.

[springmeyer]

even the install command will probably have to be modified as 2 steps are required (get the list of assets to get the id from the tarball name then download from the id).

ugh.

externalize the hosting implementations

externalized backends down the road sounds good. Now that node-pre-gyp is fairly proven/matured I'm planning on externalizing a variety of the parts: #80

[maboiteaspam]

hi,

same problem here, i want to use node pre gyp, but can t afford the s3 amazon.
I believe that if many node users would be in, we could use bittorrent as storage backend.
feross provide full implementation in pure javascript.

if such network exists, would you be in ?

[springmeyer]

@maboiteaspam - node-pre-gyp does not have a hard dependency on AWS S3. It uses pure https to fetch binaries, which can be anywhere (and is configurable via the host option in package.json). So my preference would be to have anyone wishing to host elsewhere than s3 just write external scripts that call node-pre-gyp reveal in order to get the right info to publish binaries. More details on this at #134 (comment).

[indieisaconcept]

Has anyone considered https://bintray.com/?

[maboiteaspam]

Cool!
Hope licence and so on would let us push there the binaries needed by our respective github public projects.