Moviepy: Fixed dependency versions

[jeromegrosse]

On this line the versions of the dependencies are not specified, which can create a problem as it can create compatibility problems in case of breaking changes from upstream.

[tburrows13]

Do you mean we should be specifying minimum versions or maximum versions on dependencies?

[jeromegrosse]

We should specify the versions on which we know moviepy works. If one of the dependency gets a new version, even one with breaking changes, moviepy will stop working as it will download the latest dependencies.

I created this issue as I encountered this very problem. Tomorrow I'll try to give a snippet that can reproduce the error. :)

[keikoro]

Yeah, I agree the version numbers should be fixed, and only be ones that we know work.

[jeromegrosse]

So, a bit of a follow up.

I'm not sure if it is better to create an issue but I'll first mention the errors here.

First of all, with the last version of movieio, in my case it is necessary to execute the command: import imageio; imageio.plugins.ffmpeg.download() for executing anything related with ffmpeg. It wasn't necessary with movieio 1.6 as it was bundled in the package.

I also encounter this issue: https://github.com/Zulko/moviepy/issues/376 . it is apparently related to the update of numpy, which could also be avoided if storing the dependencies versions within the setup.py file.

I'd like to mention that I'm happy to see this project live again with the PR and issues being attended. :+1:

[Julian-O]

There have been some improvements in #626 for this.

Locking in to a fixed version is problematic, because:

• Users won't get bug fixes, including security patches.
• It doesn't play well with others. If other packages insist on a different version, there will be a version conflict.
• Binaries might not exist for the version we demand, meaning that rebuilds are required. This is not trivial on every platform.

Semantic versioning allows us to specify that we accept any version, from the version we know works, up to the next breaking change (indicated by the first digit), so we can take advantage of that in the setup.py specifications.

[tburrows13]

All sorted in v2.0, if not before.