Expanded Library or example documentation.

[simotek]

For a project i'm working on i've written a simple wrapper [1] that basically wraps osc-tiny, and then calls etree to extract information in a useful way, at worst with some minor modifications (such as how the user / password is read) its probably useful example documentation for osc-tiny, at best maybe it makes sense to merge this into the osc-tiny library in some way or its own secondary linked module.

Before I tidy it up further and go down any of these paths i'd be interested in your thoughts.

1. https://gist.github.com/simotek/1aca0bcd8b178c229053fe23eafe8d91

[crazyscientist]

Hi @simotek,

thanks for sharing your thoughts 🙂

and then calls etree to extract information in a useful way

It looks to me like you ate only importing etree without actually using it. osc-tiny returns objectified XML Elements instead of etree Elements, because it's more convenient (at least for me) to handle those.

such as how the user / password is read

osc-tiny was designed as a client library, which does not store credentials on its own, but recently we added support to read the osc config and actually get credentials from osc:

https://osc-tiny.readthedocs.io/en/latest/api.html#osctiny.utils.conf.get_credentials

at best maybe it makes sense to merge this into the osc-tiny

I only had a quick look at your gist. I get the feeling you are primarily missing developer friendly "high-level" functions, whereas osc-tiny currently only covers the "low-level" API calls.

I also have some ideas for high-level functions that could be added to osc-tiny for other uses cases; it certainly will make sense to pick some parts of your code and port it into osc-tiny 👍

[simotek]

Hi @simotek,

thanks for sharing your thoughts slightly_smiling_face

and then calls etree to extract information in a useful way

It looks to me like you ate only importing etree without actually using it. osc-tiny returns objectified XML Elements instead of etree Elements, because it's more convenient (at least for me) to handle those.

I guess I was only using etree.dump()for debugging then.

such as how the user / password is read

osc-tiny was designed as a client library, which does not store credentials on its own, but recently we added support to read the osc config and actually get credentials from osc:

https://osc-tiny.readthedocs.io/en/latest/api.html#osctiny.utils.conf.get_credentials

Yeah, that does make more sense, this started out as a rapid prototyping excersize and the thing I was integrating with already had the credentials so I just used them (this file is copy pasted directly from there)so yeah I wouldn't expect to use that part in a library.

at best maybe it makes sense to merge this into the osc-tiny

I only had a quick look at your gist. I get the feeling you are primarily missing developer friendly "high-level" functions, whereas osc-tiny currently only covers the "low-level" API calls.

I also have some ideas for high-level functions that could be added to osc-tiny for other uses cases; it certainly will make sense to pick some parts of your code and port it into osc-tiny +1

Sounds good, let me know if you need any help, I'll probably eventually add a couple more high level functions for returning a list of packages in a project and probably also for returning the list of packages / projects a user is a maintainer of.

[crazyscientist]

Sounds good, let me know if you need any help. I'll probably eventually add a couple more high level functions

Take your time. I'll go on vacation from Thursday to 2022-04-25. After that, we can go through your gist and pick the feature to port into existing "extensions" or a new "high-level" extension.

returning the list of packages / projects a user is a maintainer of.

If you are interested in SLE data only, you could also query SMELT, which makes a few assumptions to store this info in a structure that is queried quicker.

[simotek]

returning the list of packages / projects a user is a maintainer of.

If you are interested in SLE data only, you could also query SMELT, which makes a few assumptions to store this info in a structure that is queried quicker.

Yeah ideally we want to make as much of it useful to general openSUSE contributors as possible so we are trying to get as much of the data out of the external buildservice as possible. There are some other things we will look at providing info on such as parts of the maintenance process that we will use smelt for.