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.

Sign up for GitHub

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

Jump to bottom

JS/Python package names improvements #100

Open
syrusakbary opened this issue Nov 24, 2022 · 2 comments · May be fixed by #102
Open

JS/Python package names improvements #100

syrusakbary opened this issue Nov 24, 2022 · 2 comments · May be fixed by #102

Comments

@syrusakbary
Copy link
Member

syrusakbary commented Nov 24, 2022 •
edited
Loading

Right now, when we generate a NPM/PyPI package for a wasmer package, we generate the name from the wasmer package name.

For example, for the python/python package we generate the name:
JS: @python/python
Python: python.

However, this can generate some issues. If I see in a codebase that @python/python is being imported, I will imagine that I can install it from npm under that name, but that namespace or package name might be used by other package or user.

I think ideally we might be able to map the bindings package name to the name in the JS/Python package manager.

Proposal

We can start using the @wasmer-package org, and map the names to be:
JS: @wasmer-package/python__python (basically map to : @wasmer-package/{namespace}__{packageName}.
Python wasmer_package__python__python

That way we can also automatically publish the bindings to NPM/PyPI when the time comes.
@Michael-F-Bryan
Copy link
Contributor

@syrusakbary, I just played around with this and I'm not sure if I like the way packages get named.

For example, wasmer/wasmer-pack is turned into wasmer_package__wasmer__wasmer_pack on Python and @wasmer-package/wasmer__wasmer-pack on JavaScript. Compare that with wasmer_pack and @wasmer/wasmer-pack under the existing naming scheme.

I know package names are just labels, but they feel kinda clunky and could be a pain for end users to import every time.

Instead of publishing to PyPI and NPM, what if we hosted our own alternate registries? Pip, NPM, and Cargo all support the concept of alternate registries, and that way we wouldn't need to worry about namespacing.

I guess it's a trade off, though. Hosting our own registry gives us lots of flexibility, but most registries require you to only have dependencies from the same registry, so it means people can't use WAPM packages if they want to publish to PyPI/NPM/Crates.io 😞

@Michael-F-Bryan Michael-F-Bryan linked a pull request Dec 1, 2022 that will close this issue
Draft
@syrusakbary
Copy link
Member Author

This can be solved easily by a new --package-name flag provided to the wasmer-pack cli.

Where the user of the CLI actually decides what's the package name.
Wasmer pack can choose the default and users can override it.

This also helps if in the future we don't include the package name metadata in the webc

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Prepare Package names for PyPI/NPM syndication wasmerio/wasmer-pack
2 participants
@syrusakbary @Michael-F-Bryan