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

nodejs PyPI package #121

Open
jbms opened this issue Feb 25, 2024 · 2 comments
Open

nodejs PyPI package #121

jbms opened this issue Feb 25, 2024 · 2 comments

Comments

@jbms
Copy link

jbms commented Feb 25, 2024

I'm not sure if this is the correct place to post this issue --- if not, please let me know which issue tracker may be more appropriate.

Many Python packages depend on Node.js --- one particularly common use case is as a build dependency in order to build client-side web resources associated with a Python package.

While it is possible to just document this dependency and require that users manually install a suitable version of Node.js, it is much more convenient to be able to declare the dependency on Node.js directly as a Python dependency, as that avoids the need for users to perform any additional steps manually.

There are currently two Python packages of nodejs that address this issue:

  • https://pypi.org/project/nodejs-bin/ by @samwillis (no longer maintained) --- packaged the nodejs official and unofficial binaries, supported a large set of platforms but due to reliance on upstream binaries does not correctly support older glibc versions.
  • https://pypi.org/project/nodejs-wheel/ by @njzjz (actively maintained) --- recently created as a replacement for the former project due to it not being maintained and due to glibc version issues.

There is also an older, abandoned project https://github.com/markfinger/python-nodejs that had a similar goal.

I recently got into contact with both @samwillis and @njzjz and discussed with them the possibility of collaborating on a single nodejs Python package that would use the official and unofficial binaries when possible for the widest platform support, while also having proper glibc version tags and supporting the older glibc versions. I think we have reached agreement on that, and with the approval of @markfinger (the owner of the now-abandoned "nodejs" Python package) will likely move forward with this under the nodejs package name.

We also agreed, though, that it would be better if this Python package could be owned by the nodejs organization itself (but with similar "unsupported" status as the unofficial builds), as that would give users greater confidence in the package, and might also provide some useful organizational structure given that more than one person might contribute to maintaining this Python package.

The exact form this ownership might take is not clear, but we would be prepared to "donate" the already-working package and continue to maintain it as needed, unless an existing Node.js organization member would prefer to take it over. The building of the Python package could happen on github actions, and the package would be hosted by PyPI, and therefore would not require any additional server resources. Potentially github actions could also be set up to trigger releasing a new Python package automatically when a new Node.js version is released, such that it might work mostly unattended.

@nschonni
Copy link
Member

I'm thinking https://github.com/nodejs/admin/ or https://github.com/nodejs/tsc/ might be a better place to raise this

@rvagg
Copy link
Member

rvagg commented Feb 26, 2024

^ agreed, this isn't the place to raise it (it is "unofficial" around here after all!!), what you want to do is get this on the table for the TSC to look at and consider whether increasing the scope of this org is in the interests of the project. Of course there are various kinds of risks involved in taking on responsibilities for things which have previously not been a responsibility, and it becomes harder where there are not existing trust relationships. Centralising things into this org is probably not the default I'd go for but sometimes there are cases where exceptions could be made because of the risks involved in not centralising.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants