6 ms·

it's very brave to release a new configuration language with no Python support today.

by bobuk 3y ago

isodev 3y ago
They start with Swift, Java, Kotlin and Go. That's already a big chunk of applications. Perhaps more will come in the future.
- shuafajdn 3y ago
  [dead]
- baq 3y ago
  No C library sounds like a purposeful omission to slow down third party integrations.
  - shuafajdn 3y ago
    [dead]
w-m 3y ago
And at the same time borrowing the name and file ending of Pythons object serialization protocol.
The_Colonel 3y ago
That's a strange way to frame it, you don't have to support every language to be successful. World domination might not even be the project's goal.
randomdata 3y ago
Python is able to load Python code at runtime, so one can use Python for configuration. A solution doesn’t need to go looking for problems that are already solved.
- Too 3y ago
  Not uncommon to have a python program that loads external half-trusted configuration, that must be sandboxed in capabilities. For in-house stuff, totally agree, just use the python code itself as the configuration.
- ahefner 3y ago
  ...and yet Python people routinely fail to grasp this and end up writing ad-hoc config language interpreters on top of yaml anyway. Granted the conveniences of Python syntax for code are mostly lost when trying to express tree structured data, and yaml flips that on its head. (Mumble, grumble, something about s-expressions...)
  - baq 3y ago
    That’s because it’s impossible to properly sandbox the config parsing. It’s also a horrible experience to debug configs. But it’s still better than templating yaml.
    - networked 3y ago
      People interested in configuring Python software in Python should look into Starlark. There are Python bindings for two versions of Starlark: Go (https://github.com/caketop/python-starlark-go https://github.com/caketop/python-starlark-go) and Rust (https://github.com/inducer/starlark-pyo3 https://github.com/inducer/starlark-pyo3). I used python-starlark-go for a time in a project that ran on x86-64 Linux and had no problems with it. (I stopped because my project's configuration turned out simpler than expected, so I switched to TOML.) Worth noting that it is specifically CPython that has been called impossible to sandbox. (2014 discussion: https://news.ycombinator.com/item?id=8280053 https://news.ycombinator.com/item?id=8280053.) It may be possible to sandbox PyPy. PyPy has a sandboxing feature its website calls a "working prototype" (https://www.pypy.org/features.html#sandboxing https://www.pypy.org/features.html#sandboxing). If someone invested in it—potentially a huge effort—it could plausibly become good enough for configuration. But, IMO, Starlark is a better choice here because it was designed for isolation from the start. If you wanted to invest in Python-as-config-for-Python, a good use of your time might be improving Starlark for Python.

it's very brave to release a new configuration language with no Python support today.

by bobuk 3y ago

it's very brave to release a new configuration language with no Python support today.

They start with Swift, Java, Kotlin and Go. That's already a big chunk of applications. Perhaps more will come in the future.

shuafajdn 3y ago
[dead]
baq 3y ago
No C library sounds like a purposeful omission to slow down third party integrations.
- shuafajdn 3y ago
  [dead]

w-m 3y ago

And at the same time borrowing the name and file ending of Pythons object serialization protocol.

The_Colonel 3y ago

That's a strange way to frame it, you don't have to support every language to be successful. World domination might not even be the project's goal.

randomdata 3y ago

Python is able to load Python code at runtime, so one can use Python for configuration. A solution doesn’t need to go looking for problems that are already solved.

Too 3y ago
Not uncommon to have a python program that loads external half-trusted configuration, that must be sandboxed in capabilities. For in-house stuff, totally agree, just use the python code itself as the configuration.
ahefner 3y ago
...and yet Python people routinely fail to grasp this and end up writing ad-hoc config language interpreters on top of yaml anyway. Granted the conveniences of Python syntax for code are mostly lost when trying to express tree structured data, and yaml flips that on its head. (Mumble, grumble, something about s-expressions...)
- baq 3y ago
  That’s because it’s impossible to properly sandbox the config parsing. It’s also a horrible experience to debug configs. But it’s still better than templating yaml.
  - networked 3y ago
    People interested in configuring Python software in Python should look into Starlark. There are Python bindings for two versions of Starlark: Go (https://github.com/caketop/python-starlark-go https://github.com/caketop/python-starlark-go) and Rust (https://github.com/inducer/starlark-pyo3 https://github.com/inducer/starlark-pyo3). I used python-starlark-go for a time in a project that ran on x86-64 Linux and had no problems with it. (I stopped because my project's configuration turned out simpler than expected, so I switched to TOML.) Worth noting that it is specifically CPython that has been called impossible to sandbox. (2014 discussion: https://news.ycombinator.com/item?id=8280053 https://news.ycombinator.com/item?id=8280053.) It may be possible to sandbox PyPy. PyPy has a sandboxing feature its website calls a "working prototype" (https://www.pypy.org/features.html#sandboxing https://www.pypy.org/features.html#sandboxing). If someone invested in it—potentially a huge effort—it could plausibly become good enough for configuration. But, IMO, Starlark is a better choice here because it was designed for isolation from the start. If you wanted to invest in Python-as-config-for-Python, a good use of your time might be improving Starlark for Python.