Dear yt devs,
TLDR: should we change the configuration format from .ini to another one
(e.g. toml)?
------------------------------------------------------------------------
Last meeting we discussed what steps were required for the 4.0 release
and one of the point was whether we should change how we handle
configurations files (e.g. to get
https://github.com/yt-project/yt/pull/1931 eventually in). Given that
changing the format of yt's configuration is a big breaking change, this
would have its place in a yt-3 to 4 transition plan.
Amon the possibilities of a new or improved configuration system, users
may be able to set some preferences per-field (e.g. have a configuration
that implements the user's wish that "velocity_divergence should be
displayed using a linear scale, with the seismic colormap"), or to pick
their favourite unit system (e.g. cgs for the astro community, mks for
the others).
I know this has already been discussed earlier (both in PR comments and
/via/ email), but let's take a moment to think about it with a fresh
perspective. I can see three possible options:
1. Keep the .ini file format and build on top of that.
_Pros:_
* no need to write a script to convert the old configuration files
to a new format
* easy to write for the user
_Cons:_
* may become increasingly cumbersome to maintain if the available
configuration keys are extended
* no support for subgroups within one configuration group, so the
configuration file may become cluttered or we'd need to handle
this manually in the codebase
2. Switch to toml
_Pros:_
* the language support semantically boolean/str/numbers (and parse
them accordingly)
* language is standardized & similar to .INI
* easy to write (but see below)
* possible to have nested configs, e.g. to set defaults for a
range of different fields:
[yt.fields.gas]
# Use linear scale by default for gas fields …
use_log = false
[yt.fields.gas.pressure]
# … except for pressure fields
use_log = true
That would be parsed natively as
{'yt': {
'fields': {
'gas': {
'use_log': False,
'pressure':{
'use_log': True
}
}
}
}
* the syntax make it explicit what type each value is, so we could
check the validity of the config when yt is loaded (for ex.
[yt]\nloglevel=nan is invalid because loglevel should be a number).
_Cons:_
* users will have to migrate their old config (if any), though we
could provide a migration script
* yet-another dependency (but we could vendor the parser, there
are small implementations)
* may be harder to write (how does a user know the expected type
of each key? Should [yt]\n loglevel by a string or a number?)
* for developers: we'd need to change the way the config is
supported in the codebase (currently we're relying on ConfigParser)
* there are some gotchas, for example boolean true is written
"true" not "True"
3. Switch to yaml or json?
What is your opinion? As a starting point, you could think about how
you'd implement the example given above to deactivate the log scale for
plots made with any field with type "gas", except pressure (is this
something we want? If so, what's the best solution to achieve it in a
meaningful way for the user?).
Regards,
Corentin
--
Dr. Corentin Cadiou
Post Doctoral Research Assistant
Cosmoparticle Initiative Hub, desk 27
University College London (UCL)
Gower St, Bloomsbury, London WC1E 6BT
mobile: +33.6.43.18.66.83
Hello yt friends!
yt 3.6.1 is now out!
It includes one backport: matplotlib 3.3.x support. See PR 2754
<https://github.com/yt-project/yt/pull/2754> and the initial bug report at
2752 <https://github.com/yt-project/yt/issues/2752> .
For release notes, see
https://yt-project.org/doc/reference/changelog.html#version-3-6-1.
Binaries for yt 3.6.1 are available via pip and conda. If you installed via
the install script or use conda to manage your python installation, you can
update yt via:
$ conda update -c conda-forge yt
And via pip if you manage your python installation with pip:
$ pip install -U yt
As always, if you have any questions, concerns, or run into any trouble
updating please don’t hesitate to send a message to the mailing list or
stop by our Slack workspace.
Thanks for being in the community!
- the yt development team
Hi yt-dev!
This week during the yt team meeting we decided to hold a meeting to plan
out our next steps with yt-4.0, specifically:
- if all PRs labeled with the 4.0 label should be blockers to a release
- what else we need to do for the 4.0 release
- what our plan is for required 4.0 features (who is doing them, do they
need help, etc.?)
- moving non-urgent PRs/issues to a later release, if relevant
Please mark your availability on the poll if you'd like to join for this
meeting!
https://www.when2meet.com/?10232055-iXucU
Madicken
Hi folks,
In https://github.com/yt-project/yt/pull/2896 I issued a rewrite for the
interactive volume rendering. There's been some discussion, but basically
the path is diverging:
* Merge in, and review via yt methods
* Split into separate package (likely following a null merge, so that the
history is preserved *somewhere*) and removing the existing interactive
volume rendering
If folks have time, chiming in on it over there would be very helpful.
Thanks!
-Matt
Calling any and all yt-users!
I am pleased to send out the 2nd announcement for *RHytHM:* *R*esearc*H*
using *yt* *H*ighlights *M*eeting! *It is taking place Dec 9-11 for a few
hours each day, and if you sign up early enough (Nov 16) we will try to
account for your time zone when settling on the exact hours!*
The goal of the meeting is for yt users to share how yt helps them with
their research. Sharing how yt helps *your *workflow may inspire the rest
of us to use yt in a way we had never even considered! We are so excited
to see what everyone is up to, and to make life easy, when you sign up for
a talk, *you can choose* if it is a longer, more detailed talk (25+5), a
shorter talk (15+5), or a lightning-style quick look at something for which
you use yt (5 mins).
This is meant to be a fun, informal meeting, so sign up to talk about *any*
aspect of yt *you* use!
As a yt user, let me share some talk ideas I hope *YOU* sign up to give:
*--*Share why phaseplots are the best plots *(I could look at
**phaseplots** for
a whole conference, honestly)*
--Share a new colormap that beats kamae *(a low bar, possibly? ...or
impossibly high?)*
*--*Show how phaseplots let you compare simulations to observations! *(to
figure out if the simulation in which we live is flawed)*
--Show how slices are way better than projections for your work *(I'll
believe it when I see it)*
--Explain a neat way you select data *(is cut_region your friend, too?)*
--Walk me through your yt extension! *(so many cool things use
yt: https://yt-project.org/extensions.html
<https://yt-project.org/extensions.html>, is yours on the list?)*
*-*-Show how phaseplots can sometimes be basically a projection, but
BETTER. *(phaseplots are so useful, amiright?)*
--Two words: volume. rendering. (*more words: is it scientifically
helpful or just gorgeous?)*
--A plot you can't quite make using yt that you feel like *should just
work*! *(lines on phaseplots, anyone?)*
*--*Surprise me with a phaseplot I haven't thought of! *(other things than
phaseplots are acceptable)*
*Please take a look and register (by Nov 16) if interested! Share with
your networks! *https://indico.flatironinstitute.org/event/722/
We look forward to seeing many of you (on zoom) in December!
Best,
The SOC
Stephanie Tonnesen
Matt Turk
Madicken Munk
John Zuhone
--
Dr. Stephanie Tonnesen
Associate Research Scientist
CCA, Flatiron Institute
New York, NY
stonnes(a)gmail.com
