Thanks for this Tim, I'll try to keep looking at this as I progress with the API.

Comment on the properties autosetup: this unfortunately was one of the things we got many complains about from other teams, most notably Anaconda. Properties either have a reasonable default (like conf or repos), or they have to be activated manually in case doing so is an important step that e.g. prevents the user from repeating certain actions (loading the sack---new repos are not considered after).

On naming: all public method names use the underscore notation which is more prevalent in the Python world. CamelCases are used for classes. Everything else follows PEP008 and https://github.com/akozumpl/dnf/wiki/Hacking

On packages and dependencies lookups: these can be done via dnf.queries. I have yet to document them.

On transactions: they already do what the linked document describes, in a different form. 'pattern' parameter is not supported by design, one should use Subject or Query for lookups.

On group operations undos: we really need to work on that.

What do you propose is the exact semantics?

The group are a little tricky, yum has 2 kind of packages:

oldstyle group just a collection of packages, if all packages in the collection is installed, then the group is installed.

groups is installed by getting the mandatory+default package names from comps and add the not installed ones to the transaction.

groups is removed by adding all mandatory+default packages for remove to the transaction.

Besides reading from comps, no special metods is needed, yum provides some, i think they are used by anaconda for for make et easier if the user select and then deselect a group.

newstyle groups are more object like so they need metods for installing, removing, updating

install_group, remove_group, etc.

When I think about it, then the undo, unselect methods is kind of weird, we have no methods for undo package actions like update, so if the install_group returns the txmbrs, then the API should be able to handle undo/unselect actions IMHO.

I must be tired :)

It should have been

groups are a little tricky, yum has 2 kind of groups:

- No auto setup is fine with me, a little more work but make easier to understand what is going on.

- naming all public API using underscore naming and camelcase class is fine. All other private methods, should start with _ to mark that they are private. Maybe making a BaseCore parent class to Base, with all the private stuff, so it is easier to se what is public API and what is private api. 

- only supporting po on install, update etc is also fine, if there is other ways to find the patterns.

It would be nice with some doc on how to work with the sack would be great :)

(In reply to Tim Lauridsen from comment #9)
> - naming all public API using underscore naming and camelcase class is fine.
> All other private methods, should start with _ to mark that they are

It does not matter what is underscored and what is not. What the API documentation's Intro [1] says applies. That is: if it's not in the documentation then it does not comprise the API and we will remove it and change it any time.

> private. Maybe making a BaseCore parent class to Base, with all the private
> stuff, so it is easier to se what is public API and what is private api. 

Absolutely not, that's an OO antipattern.

> It would be nice with some doc on how to work with the sack would be great :)

Good point. Do you have something specific besides the package queries on your mind?

[1] http://akozumpl.github.io/dnf/api.html#introduction

> > It would be nice with some doc on how to work with the sack would be great :)
> 
> Good point. Do you have something specific besides the package queries on
> your mind?
> 

It is mostly package queries, I was thinking about.

A simple example of using the API whould be nice to

import dnf
base = dnf.Base()
<something is needed to setup conf and repos (maybe some api is needed to setup
the default enabled repos>
base.fill_sack()
<do something useful>

I have done some tests but, I haveing a hard time to get the repos loaded

(In reply to Tim Lauridsen from comment #11)
> It is mostly package queries, I was thinking about.

On my list already!

> <something is needed to setup conf and repos (maybe some api is needed to
> setup
> the default enabled repos>

I'm glad you're pointing this out, that's also on my list but the high-level functions to do this are in horrible state and will need some improvements before we can claim them as a part of the API.

I got a simple example up and running :

import dnf.yum
import dnf.const
from dnf import Base
base = Base()
# read the conf settings for dnf.conf
base.read_conf_file()
# setup cache suffix and prefix 
suffix = dnf.yum.parser.varReplace(dnf.const.CACHEDIR_SUFFIX, base.conf.yumvar)
base.cache_c.prefix =  base.conf.cachedir
base.cache_c.suffix =  suffix
# load the repo infomation from repo files
base.read_all_repos()
print " =============== loading sack====================="
# setup the sack
base.fill_sack()
# list installed packages
q = base.sack.query()
for po in q.installed():
    print po

Besides the suffix & prefix setup, it looks nice :)

the suffix&prefix is fixed in the new version. mind you, you use some non-API stuff there.

Yes, these are not API, but it dont work without them :)

base.read_conf_file()
base.read_all_repos()

Tim, I am looking into providing the missing undo group methods now. I am wondering: what would be the use case? If it's for a UI to select/unselect some group (e.g. through a checkbox) then I think the app should be able to handle this in it's model code. If it's only this use case I would tend to avoid adding similar layer to DNF.

I see no need for ui for select/unselect a group.
a agree that a package manager gui should handle that, not dnf.

something like

group_install(group)
group_remove(group)
group_update(group)

whould be useful.

and some public api to get group members (names or packages)

I believe b4f23e4 which adds Base.group_upgrade() to the API is the last commit to fulfill this request, all mentioned methods are provided now.

dnf-0.5.1-1.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/dnf-0.5.1-1.fc20

Package dnf-0.5.1-1.fc20, hawkey-0.4.14-1.fc20:
* should fix your issue,
* was pushed to the Fedora 20 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing dnf-0.5.1-1.fc20 hawkey-0.4.14-1.fc20'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2014-5937/hawkey-0.4.14-1.fc20,dnf-0.5.1-1.fc20
then log in and leave karma (feedback).

dnf-plugins-core-0.0.8-2.fc20, libsolv-0.6.1-1.git6d968f1.fc20, hawkey-0.4.16-1.fc20, dnf-0.5.2-1.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/libsolv-0.6.1-1.git6d968f1.fc20,hawkey-0.4.16-1.fc20,dnf-0.5.2-1.fc20,dnf-plugins-core-0.0.8-2.fc20

Package dnf-plugins-core-0.0.8-2.fc20, libsolv-0.6.1-1.git6d968f1.fc20, hawkey-0.4.16-1.fc20, dnf-0.5.2-1.fc20:
* should fix your issue,
* was pushed to the Fedora 20 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing dnf-plugins-core-0.0.8-2.fc20 libsolv-0.6.1-1.git6d968f1.fc20 hawkey-0.4.16-1.fc20 dnf-0.5.2-1.fc20'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2014-6789/libsolv-0.6.1-1.git6d968f1.fc20,hawkey-0.4.16-1.fc20,dnf-0.5.2-1.fc20,dnf-plugins-core-0.0.8-2.fc20
then log in and leave karma (feedback).

dnf-plugins-core-0.0.8-2.fc20, libsolv-0.6.1-1.git6d968f1.fc20, hawkey-0.4.16-1.fc20, dnf-0.5.2-1.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.