allow independent py/js package releases

[rmorshea]

Right now, Python and Javascript package releases are performed in lockstep. That is, at every release we publish all packages and we do so with the exact same version for everything. This made things simple to manage in the past, but ultimately, it makes the versions less meaningful since we cannot indicate where, if at all, breaking changes have occurred with any granularity.

This set of changes allows packages to be released independently and with different versions by enforcing a new tagging scheme. Tags should now be of the form <package>-v<version>. The nox -s publish script then parses the tag and releases the named package. Releasing more than one package at a time is accomplished by applying multiple tags to the same commit.

Todo

• Add changelog for each Javascript package
• Figure out how we should handle GitHub releases (perhaps we automate it on publishing tags?)

Checklist

Please update this checklist as you complete each item:

• Tests have been included for all bug fixes or added functionality.
• The changelog.rst has been updated with any significant changes.
• GitHub Issues which may be closed by this Pull Request have been linked.

[Archmonger]

Can we also start committing the built JS into the pypi package (like we do with django-idom)?

I will need that for template tag development.

[rmorshea]

That's something we already do. The built JS is dropped under reactpy/_client

[Archmonger]

We'll have to think about how to properly document this. Right now it's pretty simple to tell users to use the same npm and pypi versions.

[rmorshea]

In general, I don't think that's something users will ever have to worry about since a compatible version of the client comes with ReactPy. The main place this matters is for developers of downstream packages (e.g. reacpy-django) since they'll need to know when, if at all, to upgrade their version of @reactpy/client when they upgrade reactpy and visa versa.

[rmorshea]

These changes would also allow us to think about restructuring under a monorepo using namespaced Python packages.

Instead of from reactpy_django import ... users would be able to do from reactpy.django import ....

[Archmonger]

Apologies, my comment was ambiguous. I meant documenting the fact that version numbers are no longer in sync.

More specifically, I'm talking about the embed into an existing webpage docs.

Although these docs may become pointless once template tag support comes out, right now that's the only way to use ReactPy properly. It might be confusing to end users to use non-synced NPM/Python versions.

Even right now, it's not properly documented. I'd feel more comfortable documenting a completely unpinned version of ReactPy client rather than @0.33.3.

[Archmonger]

Also I thought we ultimately decided the monorepo would cause more problems than it would solve?

[rmorshea]

I think this question of how to release packages independently was one of the things I thought would make a monorepo more challenging to deal with.

[rmorshea]

Difficulties around handling client/server compatibility can also hopefully be handled by handshake messages between the client and server.

[rmorshea]

I'm going to merge this. Ultimately it's a necessary change. We can sort out how we want to handle our versioning policy as we move forward. With respect to the monorepo question, in the long run I think it makes to move in that direction. However, the tooling (a la NPM workspaces or Lerna) for managing this really doesn't exist in the Python ecosystem. People seem to be thinking about how to address this need though. So who knows, maybe it will be an option in the future.