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

[Ciaran McCreesh]

Since all catapult discussion appears to be happening here, and I don't
feel like registering from some forum that may or may not be read...

Catapult, as it stands, probably isn't sanely usable in general and
definitely isn't usable for Paludis. Here's why.

The API is Broken
-----------------

* 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)

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

* No mention of EAPI anywhere.

* No mention of error handling anywhere.

* 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).

* Essentially an abstraction of Portage internals, rather than an
  abstraction of a general package manager.

* It's not clear how much of the API would be useful, or that the API
  provides enough to do something useful.

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

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

* Administration:

- version. But no name?

* System:

- find_best. What does this do if you give it foo/bar-1 foo/baz-1?
  What's the point of having this function at all?

- find_best_match. What's a search key? If it's a spec, it needs an
  associated EAPI. What if only_installed is false? Does this mean we
  want both not installed and installed stuff?

- 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? Regular expressions at this level is silly
  -- which of the zillion regex flavours do we use? Does it operate on
  installed, not installed or what?

- get_config_path. Unportable. What if the user is using some other
  config format?

- get_deep_option. Deep's a mess; making package managers emulate it via
  a command line switch is silly.

- get_environment. In no way portable.

- get_global_key. Again, unportable -- Paludis has no notion of global
  configuration.

- 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? And what about package managers that require an explicit
  --install? When you ask for --sync or whatever, off what do you base
  the command?

- get_newuse_option. Again, unportable and messy.

- get_oneshot_option. Again, unportable and messy.

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

- get_sync_command. What's the point? Why not just ask the package
  manager to do the sync?

- get_unmerge_option. Same.

- get_update_option. Same as for get_deep_option.

- get_updated_packages. Highly unclear what this really does.

- get_use_desc. package should be a cpvr.

- get_world_file_path. Unportable.

- list_categories. String or regex?

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

- split_cpv. Why the weird revision thing?

- 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.

* Package

- What do all of these do on unknown EAPI?

- compare_version. But it takes packages. What's the ordering on
  foo/bar-1 vs bar/baz-1?

- get_actual_use_flags. What's the point of this?

- get_dep_packages. Hardcoding three dep classes is icky and doesn't
  work nicely with future EAPIs. And what's the return value? What about
  when || is in operation?

- get_global_settings. No such thing as a global setting.

- get_iuse_flags. What does this do for IUSE defaults? For installed
  packages, all flags are forced.

- get_installed_use_flags. Empty list? Seriously?

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

- get_matched_dep_packages. Huh?

- 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?

- get_package_path. Ditto.

- get_package_settings. What do you mean by everything? Just metadata?
  And what about EAPI? Some things don't make sense for some EAPIs or
  some package formats.

- get_use_flags. Bad. No legit use.

- is_in_system. System is a bad name.

- is_testing. How does package.keywords alter whether a package is
  testing?

- use_expanded. Not clear how this works when things aren't really
  expanded or when expanded keys aren't known.

Why DBus?
---------

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

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?

What about persistence? What's classed as a session? Why force it down
to a single session at once?

-- 
Ciaran McCreesh