mutmut icon indicating copy to clipboard operation
mutmut copied to clipboard

Use sys.executable as default python executable

Open MaxLap opened this issue 6 years ago • 7 comments

It's more likely to be the correct Python executable in case where someone specified the executable when running mutmut. On Windows 7, there is also a weird thing with the way the search is done which makes just "python" not work with venv...

MaxLap avatar Jul 23 '19 12:07 MaxLap

This change is obviously an improvement but it has a little problem which is that that parameter can be stored in a config file and this doesn't handle that. I don't know what to do about that but maybe just check if the command starts with "python " and then replace with what you do here?

boxed avatar Jul 23 '19 20:07 boxed

That could work. This has the side-effect of printing the long command when there is a problem. I don't think that's a problem.

MaxLap avatar Jul 23 '19 20:07 MaxLap

Yea that seems like a feature.

boxed avatar Jul 24 '19 06:07 boxed

t has a little problem which is that that parameter can be stored in a config file and this doesn't handle that.

If I understand correctly, that is a separate problem of loading the config, especially configs stored before this change.

This change is also important for Unix distros, as they often have a python that points to python2, not python3.

jayvdb avatar Sep 04 '19 05:09 jayvdb

There really is no difference between the default path, the config and the command line. Or rather I'd really prefer there not to be any difference.

I am working on a new major version of mutmut that changes a lot of the config anyway so then I'll produce errors for the old config. That seems like a good time to tackle this.

I think a good default is to interpret "python foo" as call sys.executable with the argument foo. But then it could be confusing if you actually wanted "python" instead. I'm conflicted about this.

boxed avatar Sep 04 '19 15:09 boxed

Regarding this patch, and your feedback

... is that that parameter can be stored in a config file and this doesn't handle that.

If the old parameter is already stored in a config file as python ... , and it was working, it will continue to work as this is only a default. If it wasnt working, they can edit their config file.

If the new parameter value is stored in a config file, it will contain a literal complete path, which is a good thing. The user can change it if they want to, or if they need to.

Am I missing something? It seems like an acceptable interim solution for a number of bugs.

jayvdb avatar Sep 08 '19 13:09 jayvdb

Well yea. The point of storing the config is so that other people than the person who first set it up can run it. Maybe that will work and maybe it won't.

boxed avatar Sep 08 '19 13:09 boxed