[pacman-dev] Pacman configuration parser library
Happy new year! It would be useful for third-party developers to have access to the Pacman configuration file parsing functions and datatypes in src/pacman/conf.h. Would you consider providing a shared library for this (or adding it to libalpm)? It would be more reliable than third-party custom parsers. Aside from providing the actual shared object file, the only change needed* would be to remove the lines from parseconfig (conf.c) that free config->repos so that users could access repo information directly via config->repos after invoking the function (config_free will free that memory later). Regards, Xyne * It would be nice as well to have the option of parsing a file without initializing alpm, but that isn't necessary and I expect that would require more intrusive changes due to the current use of a global variable.
On 01/01/2017 03:48 PM, Xyne wrote:
Happy new year!
It would be useful for third-party developers to have access to the Pacman configuration file parsing functions and datatypes in src/pacman/conf.h. Would you consider providing a shared library for this (or adding it to libalpm)? It would be more reliable than third-party custom parsers.
Like pacini, from pacutils? -- Eli Schwartz
On 02/01/17 06:48, Xyne wrote:
Happy new year!
It would be useful for third-party developers to have access to the Pacman configuration file parsing functions and datatypes in src/pacman/conf.h. Would you consider providing a shared library for this (or adding it to libalpm)? It would be more reliable than third-party custom parsers.
Aside from providing the actual shared object file, the only change needed* would be to remove the lines from parseconfig (conf.c) that free config->repos so that users could access repo information directly via config->repos after invoking the function (config_free will free that memory later).
This is on the todo list (along with adding pacconf for easy access to the configuration from scripts). I don't think anyone is actively working on it... A
On 01/02/17 at 09:10am, Allan McRae wrote:
On 02/01/17 06:48, Xyne wrote:
Happy new year!
It would be useful for third-party developers to have access to the Pacman configuration file parsing functions and datatypes in src/pacman/conf.h. Would you consider providing a shared library for this (or adding it to libalpm)? It would be more reliable than third-party custom parsers.
Aside from providing the actual shared object file, the only change needed* would be to remove the lines from parseconfig (conf.c) that free config->repos so that users could access repo information directly via config->repos after invoking the function (config_free will free that memory later).
This is on the todo list (along with adding pacconf for easy access to the configuration from scripts).
I don't think anyone is actively working on it...
A
I don't particularly care about providing a config parsing lib with pacman and have no desire whatsoever to figure out how to get autotools to make such a lib. If it's something we're going to do though, it would probably make sense to just incorporate the pacutils parser. apg
On 01/01/17 at 11:34pm, Andrew Gregory wrote:
On 01/02/17 at 09:10am, Allan McRae wrote:
On 02/01/17 06:48, Xyne wrote:
Happy new year!
It would be useful for third-party developers to have access to the Pacman configuration file parsing functions and datatypes in src/pacman/conf.h. Would you consider providing a shared library for this (or adding it to libalpm)? It would be more reliable than third-party custom parsers.
Aside from providing the actual shared object file, the only change needed* would be to remove the lines from parseconfig (conf.c) that free config->repos so that users could access repo information directly via config->repos after invoking the function (config_free will free that memory later).
This is on the todo list (along with adding pacconf for easy access to the configuration from scripts).
I don't think anyone is actively working on it...
A
I don't particularly care about providing a config parsing lib with pacman and have no desire whatsoever to figure out how to get autotools to make such a lib. If it's something we're going to do though, it would probably make sense to just incorporate the pacutils parser.
I'd like to chime in that I would love to see pyalpm to stop using it's self written config parser. I've put it on my TODO list, but I'm not sure when I'll be able to look at it. -- Jelle van der Waa
On 2017-01-02 19:58 +0100 Jelle van der Waa wrote:
I'd like to chime in that I would love to see pyalpm to stop using it's self written config parser. I've put it on my TODO list, but I'm not sure when I'll be able to look at it.
At the risk of it becoming vaporware, I'm working on this right now. I already have a working shared library for src/pacman/conf.h (via CMake) and the beginnings of a Python extension module for working with it (so far it only includes a wrapper around "parseconfig" and a class for config_repo_t). As I was writing that module I realized that I need most of alpm so I've started writing my own Python module for that too. I'm using scripts to automatically generate code for all of the enums and structs to ensure uniformity. The idea is to provide a module with a 1-to-1 correspondence with alpm.h (all enums as globals, classes for each struct, identical function names) along with utility modules for convenience code (e.g. convert enums to strings). This will make it much easier to maintain. I'm not forking pyalpm because a) I'm using this as a learning experience and prefer to do it from scratch and b) I'm adopting a different approach. I'll make an announcement here once it's released. Regards, Xyne
On 01/04/17 at 07:48am, Xyne wrote:
On 2017-01-02 19:58 +0100 Jelle van der Waa wrote:
I'd like to chime in that I would love to see pyalpm to stop using it's self written config parser. I've put it on my TODO list, but I'm not sure when I'll be able to look at it.
At the risk of it becoming vaporware, I'm working on this right now. I already have a working shared library for src/pacman/conf.h (via CMake) and the beginnings of a Python extension module for working with it (so far it only includes a wrapper around "parseconfig" and a class for config_repo_t).
As I was writing that module I realized that I need most of alpm so I've started writing my own Python module for that too. I'm using scripts to automatically generate code for all of the enums and structs to ensure uniformity. The idea is to provide a module with a 1-to-1 correspondence with alpm.h (all enums as globals, classes for each struct, identical function names) along with utility modules for convenience code (e.g. convert enums to strings). This will make it much easier to maintain.
Interesting, are you using CFFI or are you generating C code for CPython? -- Jelle van der Waa
On 2017-01-04 08:54 +0100 Jelle van der Waa wrote:
Interesting, are you using CFFI or are you generating C code for CPython?
The latter, via the Python/C API [1]. I'm probably re-inventing wheels as I go. [1] https://docs.python.org/3/c-api/index.html
participants (5)
-
Allan McRae
-
Andrew Gregory
-
Eli Schwartz
-
Jelle van der Waa
-
Xyne