Hi Corentin, Great discussion. On Tue, Aug 21, 2018 at 4:34 AM Corentin CADIOU <corentin.cadiou@iap.fr> wrote:
Hello,
As of today, there is no way to configure yt plots per-field. One is stuck with configuration that are yt-wide (e.g. default_colormap). For example, I often find myself typing p.set_cmap('density', 'dusk'). I suggest to add a way to configure the behaviour of yt plotting interface per-field using yt configuration, so that I could set once and for all some defaults for plots. I pushed a first PR on github (https://github.com/yt-project/yt/pull/1931) and opened an issue (https://github.com/yt-project/yt/issues/1888) to discuss the feature.
Nathan and I discussed a bit about how this should be implemented in the configuration file. Since ini files are quite restricted (e.g. you cannot have subsections), Nathan suggested at one point to use the toml format (https://github.com/toml-lang/toml). However, it is incompatible with the older .ini format. For example, boolean should be in lowercase (true, false) and not Python-like (True, False), strings have to be surrounded by apostrophes, ...
Taking a step back, I suspect that the following are both true: 1) Folks who have been using yt for a lot longer are more likely to have configuration files scattered about 2) The existing config files don't actually do *that* much We've also migrated in the past, and could probably implement that again. (Kacper did it the first time.) So I don't think that this should be that big of a barrier; we could also consider the idea of having a field configuration toml file that sits next to the ini file. Do we need new dependencies if we have toml?
Another suggestion is to add each fields' configuration as a new section in the ini file. For example
[config.field_type.field_name] cmap = viridis log = False
This is what is implemented in the PR, but maybe some of you have more clever ideas about this? One fairly strong constraint is that the configuration files should be as backward-compatible as possible. If not, we'd have to write a migration script from the old to the new format.
Or have them be in a separate file, which might even make sense -- and would be consistent with the idea that we may eventually want to override these by frontend.
We should also discuss what can be configured here. There is already the colormap and log scale implemented. One very neat feature would be to be able to configure the default unit, but it may be hard to implement (e.g. how do we configure the default unit for both projection and slices?) and probably confusing for the user.
Definitely default unit for non-integrated quantities! I think for integrated quantities like projections what we could do is configure the default integration unit, and that would combine with the default unit to produce the final result.
So here are the questions. Do you think per-field configuration should be part of yt? If so what format should it use? And what are your thoughts on what should and shouldn't be configurable?
1) Yes 2) I don't particularly mind toml, but I'd rather we break hard if we're going to break from INI-style files. A second file would make sense to me.
Corentin
-- Corentin Cadiou PhD student Institut d'Astrophysique de Paris (IAP), desk 142b 98 bis boulevard Arago 75014 Paris, France
phone: +33.6.43.18.66.83
_______________________________________________ yt-dev mailing list -- yt-dev@python.org To unsubscribe send an email to yt-dev-leave@python.org