andrewrk
Juice not working in Node.js v0.12.0
Mac OSx 10.9.5 64bit Node: v0.12.0 Npm: 2.5.1
Installing juice results in the follow messaging:
> $ npm install grunt-juice-email --save-dev
npm WARN package.json [email protected] No repository field.
> [email protected] install /Users/username/project-path/node_modules/grunt-juice-email/node_modules/juice/node_modules/jsdom/node_modules/contextify
> node-gyp rebuild
child_process: customFds option is deprecated, use stdio instead.
CXX(target) Release/obj.target/contextify/src/contextify.o
SOLINK_MODULE(target) Release/contextify.node
SOLINK_MODULE(target) Release/contextify.node: Finished
[email protected] node_modules/grunt-juice-email
└── [email protected] ([email protected], [email protected], [email protected], [email protected], [email protected], [email protected])
Seems this my be an issue upstream in contextify where it hasn't fully supported the newer Node versions above 0.10.12... This may be related to #16
EDIT: Determined that the install works in Node versions up to 0.11.12, after that there seems to be some conflict or API issue that is no longer supported.
Kudos for suggesting using your compilation library by providing an example implementation.
These are some big changes to the way that Groove Basin works which bring up some philosophical questions, such as:
- Should Groove Basin depend on third party APIs for core functionality like choosing the next song?
- Should we try to come up with a more generic solution that would work for untagged music or unpopular music that might not be in Spotify?
On the more technical side, I'm also looking to confirm:
- Does the compilation library handle all exceptions properly by propagating errors?
- Do its dependencies?
@andrewrk, the way this is currently structured as a combination of several weighted inputs would make it quite easy to disable external API usage when the weight of those similarity metrics is set to zero. I could imagine a set of sliders under 'preferences' for this. I am not up to date with the state of offline music similarity libraries, but could imagine those becoming another optional input. They could also work well on un-tagged / rare music.
If the general direction towards score plugins makes sense to you, I could take a stab at refactoring the patch around one.
Does the compilation library handle all exceptions properly by propagating errors?
I'm open to suggestions. The current code hides errors from individual backends, but I could just as well tweak the interface to expose them. We don't want to fail the entire request if one of several APIs has a temporary outage, but it might make sense to provide information about such errors, and perhaps fail the response overall if none of the backends responded within the timeout.
Do its dependencies?
Yes, the web requests are all done with https://github.com/wikimedia/preq, a thin promise wrapper around request. We are using this library at high volume in production at wikimedia, so I am confident in its stability. One of the features it adds is systematic handling of errors, including raising HTTPErrors for responses with status >= 400.
