src: introduce process.release object (WIP) #493
Conversation
| READONLY_PROPERTY(release, | ||
| "libUrl", | ||
| OneByteString(env->isolate(), NODE_RELEASE_LIB_URL)); | ||
| #endif |
There was a problem hiding this comment.
Isn't it possible to reconstruct the download URL from the NODE_VERSION_* macros in src/node_version.h? The approach you've taken is not bad but it's considerably more complex than is strictly necessary, I think.
There was a problem hiding this comment.
Yes ... this is an option but this gives us more flexibility for testing and baking in arbitrary urls to releases including nightlies, I can hardwire the host in here and handle the nightlies special case with macros if you think that's the best way to go. For now this is really helpful for testing this feature so I'll leave it asis.
|
I like this 😄 A thought: Is perhaps We would just need to move the 3 URL props to the root-level of the config.gypi file, and add |
|
@TooTallNate that's a good suggestion; I'm working my way through some node-gyp changes for this and that's the really difficult end so I'll loop back here when I have something working over there. |
rvagg
added
the
semver-minor
rvagg
force-pushed
the
process.release
branch
from
061df49
to
3d25a08
Compare
|
@rvagg is anything still holding this up? |
|
Yes, I'm the holdup, we need to arrive on code that's acceptable to both node-gyp and io.js before we can land either. The current state of code is @ https://github.com/rvagg/node-gyp/compare/iojs?expand=1 but it's pending proper Windows support, it's only part-way there. I'll try and get to it this week but if I keep finding that I just don't have time to finish it up I'll put out a call for someone else to take over. |
|
Didn't I see windows gyp support land? Does that unblock this? |
|
What is the status here? Anything you need help with @rvagg? |
|
This is still blocking nodejs/node-gyp#564, which is in turn blocking npm from shipping a floating-patch free version of itself. Is there anything I can do to move this along, @rvagg? |
|
@rvagg now that you're less busy, any chance of this landing soon? Seems like a few people depend on this. |
|
.................................. |
|
@stevenvachon it'd be great if you avoided comments like these. Since a lot of people get pinged when new info arrives, we also assume that information will be beneficial to us. Thanks for understanding. |
|
@jbergstroem and other comments merely asking for status updates shouldn't also be avoided? |
|
@rvagg any progress here? |
|
@rvagg wtfux? |
while we're waiting on nodejs/node#493
|
I do dis ... it's becoming more and more urgent; I just have to squash a . few . more . things . from . my . TODO |
|
Hmm, semver-minor.. no way to port this to 1.x then? It'd probably be worth it. |
|
@Fishrock123 if the LTS working group wills it, I'm sure they can make it happen. |
|
Looks good, when to merge? |
|
Is this necessary anymore since http://www.infoq.com/news/2015/05/nodejs-iojs ? |
|
Yes because 1) io.js still exists and is still releasing and has a patched version of node-gyp that you can't upgrade and more importantly 2) we need to support nightlies and rc builds with node-gyp and this metadata provides us with the flexibility to do so. |
|
Succeeded by #2154 |
I'm messing around in node-gyp to see how workable this is and I haven't actually tested this on Windows yet although I've modified vcbuild.bat. Putting this up early to get feedback.
supersedes #491 and see also nodejs/node-gyp#564 for further discussion and an apparent 👍 from @TooTallNate on the proposal.