search

wasmerio / wasmer-pack

MIT License
49 stars 5 forks source link

JS/Python package names improvements #100

Open syrusakbary opened 2 years ago

syrusakbary commented 2 years ago

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 commented 2 years ago

@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 :disappointed:

syrusakbary commented 1 year ago

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