This behavior is intentional and will almost certainly not change. Perhaps it could be better documented, though?

I dunno, docs are pretty explicit:

# default directory in savefig dialog box,
# leave empty to always use current working directory

I'd vote to close this....

OK, If it's a wontfix I think it will be worth mentioning in the documentation for savefig that this is a potential gotcha.

I am not sure how the rcParam could be any more explicit, though I agree it was poorly named. I guess we could deprecate the rcParam and rename it guisavefig....

Well, I have to confess that I didn't come here after reading the rcParam docs - I spotted the key and tried to use it intuitively like

rc('savefig', dpi=600, transparent=True, directory='/path/to/folder')
...
fig.savefig('file.png')

Which works for the dpi and transparency.

Personally it would be useful to me to be able to set the save directory programmatically. For example, when running a pipeline that produces many figures, its convenient to set the output directory at startup and then subsequently only having to use filenames instead of the full path when saving figures.

@anntzer

This behavior is intentional and will almost certainly not change.

Just curious why you see this is as the case? I'm not proposing to change the default behaviour where rcParam['savefig.directory'] = '' - which is what most people use i think. The only change would be when the user has set rcParam['savefig.directory'] and then provided only a filename to a savefig call, the file will be saved in the rcParam directory instead of the current working directory. Calls the come via GUI interactions would be unchanged.

What will this require? Inside savefig: If rcParam['savefig.directory']is non empty and fname is path-like and not

some backend-dependent object such as matplotlib.backends.backend_pdf.PdfPages

then parse it and only if it's not absolute, prepend the rc directory. I think this will make the API more consistent. Are there people that set rcParam['savefig.directory'] and still expect savefig to save in the local directory? I think not that many, but i could be wrong.

savefig.directory is also used as a runtime location, to store the last used directory for interactive saves, if not empty. Having this suddenly start affecting non-interactive fig.savefig would be confusing.

Additionally, savefig works like open or any other IO function, defaulting to the current working directory. If it started obeying some random configuration, that would quite likely break a bunch of scripts and existing packages.

I very much agree with @QuLogic that savefig departing from the behavior of open would be a major API change and is a non-starter. That said, I also very much agree with @astromancer that the rcparam name is very confusing and suggestive of the proposed behavior.

I think the path forward here is to rename savefig.directory to interactive_savefig.last_used_directory or move this out of rcparams all together. I could also see the case for moving to a bool rc['interactive_save_fig.sticky_last_path'] and then expecting the GUI backends to stash the last used directory someplace at their module level rather than rcparams.

This came in via #1685 if people want to see the original discussion.

+1 for renaming. How about gui.save.directory?

I think save[_]fig in the name is confusing because that will always be associated with the savefig method.

I don‘t see a strong case for switching to bool. Giving directory explicitly allows for a special default place to sore images to. I don‘t think we should strip that feature (and I personally use that sometimes). If anything sticky_last_path should be an additional option. But as long as nobody asks for it, I wouldn’t go there.

I agree we should not drop the feature.

The strongest argument for switching to bool is that I think this on one of two rcparam that we expect to be changed by the library code under normal operations (the other is 'backend' which we only change once from the secret sentinel to the selected backend so the user can never (without cheating) observe it change) so it is just a bit funny / defies the expectation that "rcparams is a place for users to pass global default parameters to Matplotlib" (by being "a place for Matplotlib to stash some internal state").

I'd say that "rcparams is the space to store (global) config state".

It's not internal (and also gui.save.directory doesn't have to be internal). And yes, users can manipulate that state, with matplotlibrc config files as well as in a local context.

The distinction I was trying to draw is between the user change the state vs us changing the state.

I'm not going to push this farther and am happy with gui.save.directory

Thanks for the insights @QuLogic and @tacaswell. I'll try submit a PR when I have the bandwidth available.