Conversation
* Remove scripts we don't need. * Report progress better on fetching/compiling `libiconv`. * Preserve the license and README from `libiconv`.
The latest macOS GitHub Actions CI runners ship with a Python that is configured as "This environment is externally managed". This is a somewhat recent thing in the Python world, see: - https://packaging.python.org/en/latest/specifications/externally-managed-environments/ - https://peps.python.org/pep-0668/ We can try using virtual environments ("venvs") to manage manual package installs as the error message suggests.
We need setuptools for node-gyp to be able to do its thing
macOS 14 (`macos-latest`, `macos-14`) runners are implicitly Apple Silicon runners, at least for runners we have access to on the free tier. Node 14 isn't built for Apple Silicon. So, we can test Node 14 on older macOS, like... macOS 13. That will get us an x64 macOS runner, an arch for which Node 14 should indeed be available.
|
Also happy to adopt the CI stuff recently suggested by @DeeDeeG, though I'm happy to back it out again if they think it should be part of a separate PR. |
mauricioszabo
left a comment
mauricioszabo
left a comment
There was a problem hiding this comment.
Let's merge this, sure!
Indeed, it's our best course of action to just try the N-API version instead.
|
Failures on Node 18 (on all platforms) are not necessarily expected, but not surprising either. Failures on macOS on Node 14/16 are acceptable — two specs are failing on an obscure encoding.
|
|
I'm fairly confident the Node 18 failures are from reverting the code we cherry-picked from NAN, unfortunately :/. But this is fine for now. Progress in current Pulsar is good, doing custom stuff on separate branches for WIP branches of Pulsar is still an option. EDIT to clarify: I'm referring to the code from #1. |
3 participants
This PR proves that the state of #13 is identical to what I've done here: keep all commits, except explicitly revert the parts of #1 that change the source code.
I have more faith that this will merge cleanly into
masterthan #13 — which I made by starting from an earlier commit and cherry-picking everything except for #1.@mauricioszabo, my reasoning here is that
Once we merge this, we can point Pulsar's
package.jsonto our copy ofsuperstringfor the first time — as has been made necessary by the fact that we must explicitly build our own copy oflibiconvon macOS.