PyRO versioning

[pevogam]

Hi, what is the chance that in the future PyRO might follow versioning that is decoupled from the name? I am currently upgrading to Pyro5 and I have to rename numerous module imports, docstring Pyro4.Proxy class descriptions, and others while in practice upgrading even to a major version could be as simple as handling simply the dependencies without having to touch code.

[irmen]

Close to zero, because the package name difference is on purpose because Pyro5's api underwent major changes since pyro4. Like this, you can use both at the same time thereby allowing to gradually move a system from pyro4 to pyro5 instead of having to do it in a big bang scenario.

THat said, there's a backwards compat layer for this https://pyro5.readthedocs.io/en/latest/intro.html#upgrading-from-pyro4 It has aliases for most of the common pyro4 things.

[pevogam]

Close to zero, because the package name difference is on purpose because Pyro5's api underwent major changes since pyro4. Like this, you can use both at the same time thereby allowing to gradually move a system from pyro4 to pyro5 instead of having to do it in a big bang scenario.

Semantic versioning is a standard approach handling incompatible API changes through major increments. The "use two versions at the same time" part is a bit more complicated but I am sure there are well-established ways to do this as PyRO is not the only software requiring gradual transitions and introducing a lot of incompatibilities on major version upgrades.

THat said, there's a backwards compat layer for this https://pyro5.readthedocs.io/en/latest/intro.html#upgrading-from-pyro4 It has aliases for most of the common pyro4 things.

Yes, I noticed it but still got some errors that I didn't dive into. I will probably take a look later on, thanks.

[irmen]

@pevogam I am not aware of any way to import two major versions of a library at the same time other than the solution I went for with pyro3-> pyro4 and pyro4 -> pyro5 transitioning. I'm open to suggestions here! (although the chances for a Pyro6 are very slim)

If you have particular issues with the backwards compat layer please let us know or perhaps even suggest a way to improve it. I'm open for contributions there. I only implemented the most used parts of the api. I do think it will be quite hard to add more stuff, and impossible to add stuff that are simply removed completely from pyro such as async calls

[irmen]

By the way, even if the module namespace of pyro v5 was still pyro4, you'd still have the fact that the internal API changed substantially. So old code wouldn't run regardless. I hoped that for most purposes, simply adding a from pyro5.compatibility import pyro4 at the top of your old pyro4 code, will make it work