id summary reporter owner description type status priority milestone component version resolution keywords cc port 56184 registry: New API using registry entry objects raimue "The registry 2.0 API mostly kept the way how the registry is accessed by the port client. It is still mostly based on the old storage format, which were Tcl lists and is not using the new registry entry objects. In many parts of the port client, this is very inefficient. For example, we often check whether a specifc port is installed with `registry::installed`, which internally retrieves registry entry objects and converts them to a Tcl list. The port client then takes this Tcl list and passes the values back to `registry::entry open`, which then returns a registry entry object. There should be an API to get the entry object directly to avoid this. Another case where a more direct access to the registry would help a lot are the pseudo-ports. For example, to get the ""leaves"" pseudo-port, we first retrieve a list of installed ports from the registry as a Tcl list, walk over them with a `foreach` to filter out those without dependents, also get the full list of unrequested ports a Tcl list and then calculate the intersection between the two. This could actually be done in a single SQL query to the database. Note that I am not proposing to use SQL directly for the second point, but we need to add efficient ways to query the registry for this. Either create a registry API that is flexible enough to specify this or just create a registry function to get ""leaves"" that is consistent and hides all the internal details. To avoid breaking all existing functionality or requiring to rewrite everything at once, I propose we create a new namespace of `registry2::` procs that introduces a newly designed API, that makes use of the registry entry objects. This can then be used to incrementally replace functionality in the port client and macports1.0." enhancement new Normal MacPorts Future base