Re: [gentoo-guis] Why I don't like catapult

[René 'Necoro' Neumann]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

My replies ;)

One important remark: I always see the things from the API-user view. I
have to use this API in a package manager GUI and thus want to have the
API to specify certain functionality.

Ciaran McCreesh schrieb:
> * use of cpv throughout. cpv isn't enough to uniquely identify an ID,
>   especially if there're overlays. cpvr is closer, but still doesn't
>   work if you need to deal with virtuals directly (rather than the thing
>   provided by the virtual)

CPVR sounds reasonable ... and what about using virtual/* for virtuals?
Btw: There was the idea of providing a "get_virtuals" function....

> * use of regexes throughout. Every language defines its own, different
>   regex dialect. There's no portability between languages.

True - I thought of using some kind of globbing - thus only allowing "*"
and "?" (and perhaps "^" and "$")

> * No mention of EAPI anywhere.

Why would this be needed? This is only true if "catapult API" == "EAPI".

> * No mention of error handling anywhere.

True. Currently exceptions are only passed to the caller - but this
should definitly be specified somewhere.

> * Generally lots of hard-coded ebuildy things that don't map well onto
>   future EAPIs or handling of non-ebuilds (e.g. native CRAN support).

For me - gentoo package management is all about ebuilds. So I can't see,
what should changed there.
The only thing that should be provided is a feature similar to EAPI (the
 "catapult API"), so that additional stuff can be specified later on. I
don't see a point in thinking about things, that may come somewhere in
the future.

> * It's tied onto a single user configuration setup, and has no sane way
>   of handling multiple configurations or unconfigured operation.

I don't understand this ...

> * sets don't map on to package manager sets.

This can easily be changed. But nevertheless, some catapult-wide sets
should be defined, that map onto the specific ones in the package
managers (e.g. catapult.SET_ALL should be replaced by the specific set
in the different managers)

> * Administration:
>
> - version. But no name?

I saw this myself some days ago... Really a flaw - but one simple to fix ;)

> - find_best. What does this do if you give it foo/bar-1 foo/baz-1?
Undefined atm.
>   What's the point of having this function at all?
See very first remark.

> - find_best_match. What's a search key? If it's a spec, it needs an
>   associated EAPI.
True.
> What if only_installed is false? Does this mean we
>   want both not installed and installed stuff?
Yes. - But perhaps, instead of the "only_installed" flag used here and
there, a set-name should be provided. (Which then can be "installed",
"uninstalled" or whatever).

> - find_packages. As find_best_match for search key. What disambiguation
>   is performed upon the atom? What happens if you pass it something like
>   'git', which is ambiguous?
Return everything that fits. It should be on the users side to translate
it into something useful.

> - get_config_path. Unportable. What if the user is using some other
>   config format?
But the configs (read: package.mask, package.use etc.) have to be at a
specified unique location, don't they?

> - get_deep_option. Deep's a mess; making package managers emulate it via
>   a command line switch is silly.
If you don't have an equivalent: Return "".

> - get_environment. In no way portable.
True. Should be dropped. I used it to get unwanted things out of the
environment. (E.g. modify EMERGE_DEFAULT_OPTS). But this is really a
user thing and should not be here.

> - get_global_key. Again, unportable -- Paludis has no notion of global
>   configuration.
get_global_settings and get_package_settings should be merged anyway.


> - get_merge_command. There's no nice way of using whatever this returns.
>   And it's pointless -- why not just ask the package manager to do the
>   merge?
Because catapult should be passive: I.E. only provide information and
does not do anything that could be harmful.

> And what about package managers that require an explicit
>   --install?
Return: ["pkgmgr", "--install"]. Everything that has "get_xxx_command"
should return the complete commandline.

> - get_newuse_option. Again, unportable and messy.
>
> - get_oneshot_option. Again, unportable and messy.
Why unportable? - See the remarks to "--deep".

> - get_pretend_option. Again, unportable and messy. And probably useless
>   -- what would you do with this?
True.

> - get_updated_packages. Highly unclear what this really does.
Returns a list of packages, that can be updated. Similar to what
"eix-sync" shows at the end of the run.

> - get_world_file_path. Unportable.
True.

> - list_categories. String or regex?
Has to be defined.

> - sort_package_list. You don't want stuff sorted the way it's sorted by
>   Paludis. You might want a well defined sort.
True.

> - split_cpv. Why the weird revision thing?
What's so weired about it?

> - update_world. Huh? In some ways pointlessly specific, in some ways way
>   too vague. And what's this use flag stuff? We finally just about got
>   people away from setting use flags in places other than config files,
>   and for good reason.
Rember: Passive. It should return the packages, that WOULD be updated,
if a world-update (or alike) would be run. The parameters are there, to
run different scenarios. (Portato for example uses this, to generate the
list - taking into account the user saved flags, which aren't saved to
configs yet.)

> - What do all of these do on unknown EAPI?
Again: Why does the API have to care about EAPI? - It's the providers
job to care about it.

> - compare_version. But it takes packages. What's the ordering on
>   foo/bar-1 vs bar/baz-1?
Currently it would return: ("bar-1", "baz-1") as bar < baz. But this can
easily specified different. And a good point to think about error
handling again.

> - get_actual_use_flags. What's the point of this?
In general: Returns all useflags currently set (even the package
specific ones). It additionally has the ability to merge in some other
flag settings. (Ok - the description in the API-document is a little bit
... strange).

> - get_dep_packages. Hardcoding three dep classes is icky and doesn't
>   work nicely with future EAPIs.
Is only hard-coded in the document. (Count this as a doc-error.)

> And what's the return value? What about when || is in operation?
WWPMD (what would the package manager do): Simplified: Pass the
dep-string to the package manager and see what he does with it. The
result is returned.

> - get_iuse_flags. What does this do for IUSE defaults? For installed
>   packages, all flags are forced.
defaults are returned verbatim. I used to define "forced flags" as: "The
flags the user can't change." (like userland_GNU or use.mask'ed flags)

> - get_installed_use_flags. Empty list? Seriously?
DBus does not know the "empty value". The signature has to be kept in
all cases. So: yes - empty list. (Other choice would be an exception...)

> - get_masking_reason. Is the return value supposed to be used by
>   anything other than a human?
I doubt it.

> - get_matched_dep_packages. Huh?
Return all packages the cpv depends on, but which are already installed.
"get_dep_packages" and "get_matched_dep_packages" can surely be merged.

> - get_overlay_path. What if it's in an overlay with no on-disk location?
>   What if it's in some format the end tool doesn't recognise?
The end tool's problem I'd say.

> - get_use_flags. Bad. No legit use.
Doc error. Has already been removed several weeks ago.

> - is_in_system. System is a bad name.
Renaming is easy :)

> - is_testing. How does package.keywords alter whether a package is
>   testing?
Just a naming issue - I use "testing" for things that are keyworded
"~KEYWORD".

> - use_expanded. Not clear how this works when things aren't really
>   expanded.
Return "". The naming is bad here too.

> or when expanded keys aren't known.
When should that happen?

>
> Why DBus?
> ---------
>
> What's the point in using DBus? What does it add over a simplified
> library with bindings?

Library bindings have several disadvantages:
- - Providers have to be coded in C.
- - How to access portage internals from C-Code? Yes: You can implement
python-calls in C... but I think this is messy.

Dbus advantages:
- - allows some interesting structures: Like dbus+ssh: Contact the
Catapult-Service on one machine from another one (remote adminstration)
- - bindings already provided
- - caching: For example the portage internal caches are kept and don't
have to be recreated each time something using catapult is started.

> How does the whole privs thing work? Should anyone who can talk by DBus
> be allowed to perform privileged operations? Should anyone who can't
> perform privileged operations be allowed to do unprivileged operations?
I thought of having Catapult being a passive thing. So there is no way
of doing privileged actions.

> What about persistence? What's classed as a session? Why force it down
> to a single session at once?
Easier to implement. But it isn't forced. If the provider implements
sessions (e.g. using the Dbus-sending-adress as a key) w/o extending
API, I can't see a problem.

Regards,
Necoro
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD4DBQFH784w4UOg/zhYFuARAnZRAJ4hnjiH/2yycAiDCXLnst2EpesyuQCWJNNs
6gPL9qWeiaFgCGzpwbT9cA==
=Pdi+
-----END PGP SIGNATURE-----
-- 
gentoo-guis@l.g.o mailing list