I looked over libconf and it seems like a good library that I don't mind
having as an optional dependency for yt. In particular, it's:
* Reasonably up-to-date and maintained (last release early this year)
* Pure python, supporting python 2 and 3, with a universal wheel available
on pypi
* Permissively licensed.
While it would be nice if we could do this without adding a new dependency,
if pyparselibconfig isn't sufficient, and Britton doesn't want to work on
fixing it, I think the suggested approach is fine (unless someone steps up
to fix pyparselibconfig).
If we do decide to go this route, I'd prefer it if we remove pyparselibconfig
and drop support in the Enzo frontend for libconfig parameter files in
enzo-3.0. In the real world, I don't think many (any?) datasets were
produced using that format, since the PR adding support for it was never
merged, and I'd prefer we don't have known-buggy code in the codebase to
trip up any possible future users.
On Mon, Sep 18, 2017 at 3:38 PM, Britton Smith
Hi all,
I am working on a new yt frontend for the Enzo-P code. Enzo-P outputs runtime parameters in a libconfig format and I am looking for a reliable package to read this.
yt has a libconfig-style reader in yt/utilities/pyparselibconfig, but it does not seem to parse Enzo-P parameter files correctly. I have tried a few other python libconfig parsers that do parse them correctly, so I believe the problem is with the yt module. For what it's worth, the only use of yt's libconfig parser is in the Enzo frontend for a certain style of Enzo-3.0 data, but it doesn't look like this is being tested, nor do we host any sample data of this format.
I have a PR open for the Enzo-P frontend here https://github.com/yt-project/yt/pull/1490 that makes use of an external package, called libconf https://pypi.python.org/pypi/libconf. I've implemented this as an on-demand import, so it will only be required if you're actually loading Enzo-P data.
The pros for libconf are that it's pure python, pip installable, has a permissive MIT license, and works in both python 2 and 3. The con is of course that this adds a new dependency. Personally, I would prefer not having to maintain our own module to do this, but I'm open to other opinions.
What are people's thoughts on adding this dependency?
Britton
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org