Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Should all the python and shell tools be rewritten into js? #416

Closed
ysmood opened this issue Jan 14, 2015 · 11 comments
Closed

Should all the python and shell tools be rewritten into js? #416

ysmood opened this issue Jan 14, 2015 · 11 comments
Labels
discuss Issues opened for discussions and feedbacks.

Comments

@ysmood
Copy link

ysmood commented Jan 14, 2015

So that io.js will depend on itself. Then more js programmers will be able to read and contribute to the tool chain?

Maybe the shell scripts can also be transformed into js easily. Since there are thousands of great modules in the npmjs.org. Maybe GNU make can also be decoupled.

Then the prerequisites may be like this (just joking):

  • gcc and g++ 4.8 or newer, or
  • clang and clang++ 3.3 or newer
  • io.js
  • libexecinfo (FreeBSD and OpenBSD only)

Then the build:

npm install
npm run config
npm run build

Besides, I think io.js may be much faster and lighter than python to handle these staffs.

@mscdex
Copy link
Contributor

mscdex commented Jan 14, 2015

One of the problems I think is that it'd require you to have node/iojs installed already, which would not work if you were doing a build/install for the first time...

@bnoordhuis
Copy link
Member

The way forward with gyp and node-gyp has been discussed at some length in #133.

@piranna
Copy link
Contributor

piranna commented Jan 14, 2015

@ysmood, what you propose is similar to what I'm already trying to do on [NodeOS+(https://github.com/NodeOS/NodeOS) :-P Definitely, having all the build tools written in Javascript is the way to go. It's true that this would means to have installed Node.js/io.js, but it could be downloaded previosly (or a stripped version) as another dependency if it's not available.

@mscdex
Copy link
Contributor

mscdex commented Jan 14, 2015

If you need to download iojs binaries to compile iojs, why not just keep the original iojs binaries and use them instead of compiling? ;-)

@piranna
Copy link
Contributor

piranna commented Jan 14, 2015

You need a C compier to compile a C compiler ;-) This is what's called "bootstrapping" :-D I don't think is an irrational requeriment to have a pre-compiled (stripped) Node.js/io.js binary to generate another one, maybe a newer version or compiled with some special flags or for another platform...

@ysmood
Copy link
Author

ysmood commented Jan 15, 2015

@mscdex If a OS can install python, why not a stable version of io.js? Will that be harder to do so?

@jbergstroem
Copy link
Member

I think a similar effort shouldn't have to start with gyp -- take for instance tools/bench.py.

@chrisdickinson
Copy link
Contributor

I'm -1 on changing the non-gyp tools to JS. The existing (non-gyp) tools work, and work well. It would take a non-trivial amount of effort to rewrite them, and we'd run headlong into the bootstrapping problem. As @othiym23 mentions in the other thread, while bootstrapping is possible it's rarely pleasant. We would be taking pains to replace something that silently works at present with something that is worse for the same purposes.

The big exception is GYP, which requires that end users of io.js and npm have Python installed. Google is abandoning GYP for GN, which is unsupported outside of the larger Chromium project, which precludes us from using it. For our purposes, we'd like the following properties from whatever succeeds GYP:

  1. compatible with existing GYP files in the npm ecosystem
  2. can easily be compiled stand-alone for building iojs itself (i.e., does not need an iojs runtime to operate).
  3. does not require a separate language runtime to build native modules on end-users computers.

Due to point 3, we're either shipping multiple binaries for different architectures, or we're using the one runtime we have available at that point – iojs. @indutny's suggestion is pretty interesting: write the tool in C and compile it to JS with emscripten for use on end-user's systems*. This sidesteps having to ship multiple binaries along with npm (directly or indirectly.) Whether the tool is written in C, compilable JS, Rust, Go, or assembly, the common ground is that the language ought to be easily compiled into a binary for the purposes of building iojs itself.

Replacing working infrastructure tools that don't have to end up on end-user systems with tools that require bootstrapping is a net loss, I think. We're looking at rewriting GYP in not-Python because it does end up on user systems, currently requires an extra language runtime, and we're going to have to start maintaining it (or a replacement tool) soon.

*: or, alternatively, writing the tool carefully in a compilable subset of JS and running it through something like js.js to produce a native binary.

@jbergstroem
Copy link
Member

@chrisdickinson They do work. Lets say we want new features - such as adding junit output from the test runner, or talking to the upcoming new build software thats being planned; should these be continuously built as part of the python suite? I think that converting them [the python tools] gradually while the gyp effort is running in parallel wouldn't necessarily be a bad thing.

@chrisdickinson
Copy link
Contributor

It would be easier to add a single test output formatter to the existing system than to rewrite test.py: we would not have to solve the "need a working iojs/node to run tests/benchmarks" problem; and we eliminate a variable from the test equation ("did things break because of the test, the new code I wrote affecting the test, or the new code affecting the test runner Itself?")

On Jan 15, 2015, at 2:45 AM, Johan Bergström [email protected] wrote:

@chrisdickinson They do work. Lets say we want new features - such as adding junit output from the test runner, or talking to the upcoming new build software thats being planned; should these be continuously built as part of the python suite? I think that converting it gradually while the gyp effort is running in parallel wouldn't necessarily be a bad thing.


Reply to this email directly or view it on GitHub.

@Fishrock123 Fishrock123 added the discuss Issues opened for discussions and feedbacks. label Jan 30, 2015
@cjihrig
Copy link
Contributor

cjihrig commented Feb 15, 2015

Closing, as this thread seems to have died.

@cjihrig cjihrig closed this as completed Feb 15, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discuss Issues opened for discussions and feedbacks.
Projects
None yet
Development

No branches or pull requests

8 participants