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

[ysmood]

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]

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]

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

[piranna]

@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]

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]

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]

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

[jbergstroem]

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

[chrisdickinson]

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]

@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]

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 notifications@github.com 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.

[cjihrig]

Closing, as this thread seems to have died.