Incompatibility with moto 5

[jayvdb]

Incompatibility with moto 5

[piskvorky]

@mpenkov Distro packaging is standard – having a stable, vetted, known-to-work version of a package in an official distribution can be beneficial.

However I agree that making such packaging work is "not our problem". In the sense that we're happy to accept PRs that improve smart_open / streamline the packaging (to the degree they don't break other people's workflows) but unfortunately have no capacity to get deeply involved. At least I don't :)

@jayvdb are you able to submit a PR? What is actually needed to support that new version of moto? As opposed to commenting out tests, which we probably don't want. Did they just rename methods / shuffle them around, or are the moto changes more substantial?

[jayvdb]

Yes, openSUSE and all distro packaging systems AFAIK can apply patches as part of the package-building process. We usually also submit patches upstream, which I have done in the past here in this project.

You can see all the distros which package smart-open at https://repology.org/project/python:smart-open/versions . It is a result of being popular. A typical distro user doesnt want smart-open - they want some other package which uses smart-open - see https://www.wheelodex.org/projects/smart-open/rdepends/ for the likely candidates.

This issue is not about lots of packaging systems having varying needs. All distros work the same way - they choose one version of each dependency and eventually figure out how to get them all working together. A rolling release just does this a bit quicker and more often. This issue is about compatibility with latest moto. Eventually it will need to be done. This issue is about openSUSE identifying the incompatibility, and being on the hook for helping get it fixed.

[mpenkov]

Unless someone is willing to go through the code base and work out what the problem with moto 5 and onwards is, I think we'll re-release smart_open with the moto pinned to <5.

Something changed on the moto side going to version 5, I personally don't have the time to work out what that was.

[jayvdb]

pinning will not solve the distro packaging problem. Once a distro has choosen moto 5, all other packages need to either support that version, or be deleted from the distro. We dont have multiple versions of moto in the distro. On openSUSE Tumbleweed (which is a rolling release), there is an automated service which nominates a package for deletion if it hasnt built for 6 weeks. I can decline that deletion, but that only buys a bit more time. Usually at that stage, I figure out the problem and send a patch upstream.

This problem can be partially "solved" pretty easily by allowing testing of s3 support to be disabled.

e.g. instead of @moto.mock_s3()\ndef foo(..): ..., doing something like

def foo(..): ...

if hasattr(moto, 'mock_s3'):
    foo = moto.mock_s3(foo)

[mpenkov]

@piskvorky What do you think is the best course of action here? My opinion is that the above packaging approach (a distro chooses some version of a package, and then expects everything to work with that particular version) is poor. Personally, I don't understand why smart_open (or gensim, or anything else that's on PIP) even needs to be a an openSUSE package. There are already many package managers: pip being the main one, conda being another, for people who can't live without it); why introduce yet another one? More importantly, do we have the bandwidth to make sure smart_open works with yet another package manager?

@jayvdb Hypothetically, could you patch the smart_open tests as required as part of your package-building process?

[jayvdb]

#802 probably does the trick

[jayvdb]

Is a new release planned for the next few weeks? There hasnt been a release for a while, and a security fix has been merged since the last release. If a release is coming, I'll wait until the release before updating the openSUSE package.

If not, I'll add a patch to the openSUSE package.

[mpenkov]

I'll make a new release this week