Skip to content
This repository has been archived by the owner on Feb 12, 2024. It is now read-only.

feat: pkg binaries #1007

Closed
wants to merge 1 commit into from
Closed

feat: pkg binaries #1007

wants to merge 1 commit into from

Conversation

mkg20001
Copy link
Contributor

@mkg20001 mkg20001 commented Sep 8, 2017

Ref #998
With this pr it is possible to create binaries that embed the natives and commands (npm run pkg).
The module used to do that (https://github.com/mkg20001/pkg-natives) still isn't finished but the binaries seem to work.

Notes:

  • Currently linux only
  • Mac OSX may work (travis ci didn't run yet for mac)
  • Windows probably not (added thanks to appveyor)

@dryajov
Copy link
Member

dryajov commented Sep 9, 2017

I really like this, but we need tests to make sure that the generated package is working. As I ramp up on js-ipfs, I'm not entirely sure whats the best approach to test this is in the context of the package. Should we adapt ipfs-ctld to be able to work with go/js-ipfs/js-ipfs-pkg daemons, how do we run the sharnes tests against this, etc...

I'd love to hear some ideas from: @victorbjelkholm @diasdavid @dignifiedquire

Other than that 💯 !

@daviddias daviddias added exploration status/deferred Conscious decision to pause or backlog labels Sep 12, 2017
@victorb
Copy link
Member

victorb commented Sep 19, 2017

My first concern is adding another surface that we are gonna have to maintain for maybe not that big benefit. As I understand, the only benefit we get from packaging js-ipfs this way is that we get a binary that comes with nodejs, so it's not necessary to install the runtime.

Question regarding how packaging of modules happens as well, we're gonna have to have builds for windows, osx and multiple different linux dists, which I'm not sure we're ready to take on just yet.

For testing purposes, it might be better to use go-ipfs and js-ipfs as containers instead, as we already have infrastructure for both deployment and testing, when it comes to containers.

@dryajov
Copy link
Member

dryajov commented Sep 19, 2017

I agree with @victorbjelkholm, this will definitely add to the maintenance burden for relatively little gain from the project perspective, but it is a really cool option if we ever want/need to distribute js-ipfs as a binary. Also, now that @mkg20001 did the legwork, it is an option for the community to use if such a need arises.

👍

@mitra42
Copy link

mitra42 commented Sep 19, 2017

I tend to agree, for our library we use browserify which bundles the parts it needs of js-ipfs along with other stuff into a single binary, so a pre-bundled binary doesnt help as much.

@daviddias daviddias added status/ready Ready to be worked P3 Low: Not priority right now and removed status/deferred Conscious decision to pause or backlog labels Oct 17, 2017
@mkg20001
Copy link
Contributor Author

mkg20001 commented Nov 19, 2017

I tend to agree, for our library we use browserify which bundles the parts it needs of js-ipfs along with other stuff into a single binary, so a pre-bundled binary doesnt help as much.

@mitra42 What you are talking about is a bundle (aka just a bunch of js code in a single file that can't run without nodejs or a browser). What this adds is a standalone executable similar to go-ipfs's .exe file that can be launched without having the nodejs runtime installed.
Btw, js-ipfs is already pre-bundled (just look into node_modules/ipfs/dist)

@daviddias daviddias added status/deferred Conscious decision to pause or backlog and removed status/ready Ready to be worked labels Jan 25, 2018
@daviddias
Copy link
Member

Closing ref: #998

@daviddias daviddias closed this Feb 15, 2018
@ghost ghost removed the status/deferred Conscious decision to pause or backlog label Feb 15, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
exploration P3 Low: Not priority right now
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants