{"action":"opened","issue":{"url":"https://api.github.com/repos/rustbridge/neon/issues/117","repository_url":"https://api.github.com/repos/rustbridge/neon","labels_url":"https://api.github.com/repos/rustbridge/neon/issues/117/labels{/name}","comments_url":"https://api.github.com/repos/rustbridge/neon/issues/117/comments","events_url":"https://api.github.com/repos/rustbridge/neon/issues/117/events","html_url":"https://github.com/rustbridge/neon/issues/117","id":175805663,"number":117,"title":"design a deployment workflow","user":{"login":"dherman","id":307871,"avatar_url":"https://avatars.githubusercontent.com/u/307871?v=3","gravatar_id":"","url":"https://api.github.com/users/dherman","html_url":"https://github.com/dherman","followers_url":"https://api.github.com/users/dherman/followers","following_url":"https://api.github.com/users/dherman/following{/other_user}","gists_url":"https://api.github.com/users/dherman/gists{/gist_id}","starred_url":"https://api.github.com/users/dherman/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/dherman/subscriptions","organizations_url":"https://api.github.com/users/dherman/orgs","repos_url":"https://api.github.com/users/dherman/repos","events_url":"https://api.github.com/users/dherman/events{/privacy}","received_events_url":"https://api.github.com/users/dherman/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/rustbridge/neon/labels/enhancement","name":"enhancement","color":"84b6eb"}],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":0,"created_at":"2016-09-08T16:54:31Z","updated_at":"2016-09-08T16:54:31Z","closed_at":null,"body":"Deploying an _app_ with Neon is fine, but deploying a _lib_ will be harder until we can make it relatively seamless for downstream consumers of the lib (including transitive dependents) to be completely oblivious to the dependency on Neon and Rust.\r\n\r\nBroadly, there are two possible approaches: 1) automate the process of installing Rust so downstream consumers can silently build their Neon dependencies on the fly, or 2) streamline the process of shipping precompiled binaries of a Neon lib.\r\n\r\nOption 1) is attractive in theory, since it means neither library authors nor library consumers have to do any work. But I'm not really sure how to make it work, and even if we do, it could generate excruciatingly long `npm install` wait times as Rust is downloaded and installed and then as the Neon dependencies are compiled.\r\n\r\nOption 2) seems more achievable but still has a number of challenges. I'll spell out some constraints and ideas I can think of, but **I'm really interested in getting ideas and feedback**.\r\n\r\n_Constraint:_ Pushbutton precompilation.\r\n\r\nIt should be possible to generate cross-compile binaries for multiple platforms with a single command -- maybe this can be achieved with prepublish hooks alone, or maybe we should hijack the workflow with a `neon publish` command.\r\n\r\n(This is going to depend on the state of Rust cross-compilation. Would be great to get @brson's or @alexcrichton's input here.)\r\n\r\n_Constraint:_ Deploy just one binary per architecture.\r\n\r\nThe Node and V8 ABIs are not stable, which means that a naive design would require library authors to deploy a combinatorial explosion of (# of supported Node versions) × (# of supported architectures) precompiled binaries. But if we can build an ABI-stable abstraction layer between Neon and Node, then it should be possible to precompile once per architecture in a way that should be stable across multiple Node versions. (This is a little tricky since Node changes all sorts of things, like the ABI of a module's metadata. But with a little courage and a lot of caffeine...)\r\n\r\nIt's obviously impossible to predict all future changes to Node and V8, but since Neon attempts to mostly hew to core Node and JS semantics, which are forced to retain compatibility with the world's JS content, it should be a _relatively_ safe bet that we can create a stable API that surfaces that semantics, and only the ways in which Node and V8 surface those API's will be what changes.\r\n\r\nBTW, I don't think NAN really helps here, since it only attempts API compatibility but not ABI stability.\r\n\r\n(I believe @carllerche has been through this kind of experience before -- would love his advice!)\r\n\r\n_Constraint:_ Make it possible to fall back to compilation.\r\n\r\nIt seems like it should still be good to allow downstream consumers to compile a Neon library from scratch, so that lib authors don't *have* to precompile for all supported architectures.\r\n\r\nThat's what I've got so far. Ideas? More constraints?"}}
{"actor":{"display_login":"dherman"}}