I am not completely sure that this is the correct thing to do but it would make it easier for many people on windows to use imagemagick so I think that I am positive.

What about first testing magick with shutil.which('magick') and then path + magick to avoid adding a long path to bin_path when it is not necessary?

Are there cases when it exist a magick.exe that doesn't do the same thing as convert.exe? If not I would suggest to first test magick then path+convert.exe and last path+magick.exe

What about first testing magick with shutil.which('magick') and then path + magick to avoid adding a long path to bin_path when it is not necessary?

This PR just fixes the existing functionality (initializing mpl settings from the registry settings created by ImageMagick installers on Windows) for the ImageMagick >= 7.

Using a magick executable found in the executable search path seems like a good idea to add, but probably not in this PR and not Windows only (?).

I think that it would fit into this pr but it is not that important either. I just think that it would be better to change the rcparameter to magick instead of long path + magick.exe when that is the way you would do it manually (if the path is set but the default settings assumes that anyway).

Thanks!

Would this still be eligible for 3.0, or should it go in 3.1?

Is it assured that when you install imagemagick > 7 on other systems (linux, mac) that they always install a convert?

At least https://www.imagemagick.org/script/porting.php documents that "To reduce the footprint of the command-line utilities, these utilities [convert, etc.] are symbolic links to the magick utility. You can also invoke them from the magick utility, for example, use magick convert logo: logo.png to invoke the convert utility."
(In fact, this leads to the question of why these utilities are not present on Windows.)

Let's milestone this for 3.0 and ping @tacaswell for the final decision.

In fact, this leads to the question of why these utilities are not present on Windows

These are considered legacy utilities. There's an option in the ImageMagick >= 7 installer (disabled by default) to install the utilities.

This option is disabled by default, so most users will not check it.

So my question is essentially: Does a similar "installation" process happen for Linux / Mac such that people could end up with Imagemagick without convert binary?

@cgohlke My point is that the porting docs don't even mention the fact that they may not be installed. But that's not particularly relevant as we're stuck with the actual behavior on Windows anyways.

@ImportanceOfBeingErnest Most Linux users would get imagemagick from their distro packages. Arch Linux packages IM7 including the "convert" command. None of Fedora (28), Debian (unstable), Ubuntu (18.04) appear to even package IM7 at all. So in practice that means that anyone who has IM7 without a "convert" command likely compiled IM themselves -- I wouldn't worry too much about that case.

Many Linux distros didn't upgrade to IM7 specifically because of the lack of the old executables.

I'd merge this as fixing a problem, and defer the discussion of a more general fix to someone finding that to be a problem. However, I don't have a PC, and can't test that this actually works, and it has no test coverage. If other reviewers are sure it works and don't think it needs test coverage, they should feel free to merge.

@meeseeksdev backport to v2.2.x

Owee, I'm MrMeeseeks, Look at me.

There seem to be a conflict, please backport manually. Here are approximate instructions:

1. Checkout backport branch and update it.

$ git checkout v2.2.x
$ git pull

2. Cherry pick the first parent branch of the this PR on top of the older branch:

$ git cherry-pick -m1 799ab40a13957e5c5aba8a69686791263e33f6f9

3. You will likely have some merge/cherry-pick conflict here, fix them and commit:

$ git commit -am "Backport PR #11847: Use ImageMagick's magick.exe if convert.exe is not installed"

4. Push to a named branch :

git push YOURFORK v2.2.x:auto-backport-of-pr-11847-on-v2.2.x

5. Create a PR against branch v2.2.x, I would have named this PR:

"Backport PR #11847 on branch v2.2.x"

And apply the correct labels and milestones.

Congratulation you did some good work ! Hopefully your backport PR will be tested by the continuous integration and merged soon!

If these instruction are inaccurate, feel free to suggest an improvement.