commit: d7c741b4f17ba72959bbaccbec5b9860e37c8531
Author: Brian Harring <ferringb <AT> gmail <DOT> com>
AuthorDate: Thu Nov 27 12:22:20 2025 +0000
Commit: Brian Harring <ferringb <AT> gmail <DOT> com>
CommitDate: Thu Nov 27 12:25:28 2025 +0000
URL:
https://gitweb.gentoo.org/proj/pkgcore/pkgcore.git/commit/?id=d7c741b4
chore: wipe plugin implementation.
1. it's dead code that wasn't deleted- the usage was explicitly wiped in '22.
2. that's <py2.6 code, complicated by the py3k transition. It's not code that
worth rehabilitating
3. pkgdev.objects will be rewritten to incorporate the point of the plugins
layer;
transfer the 'good' in.
4. that in turn will eventually be broken out into snakeoil as a registry,
since these
days that pattern is viable and standarized.
Note; due to py2k reasons, a lot of this usage was duck typed for things like
the
ConfigHint layering. Those pieces remain, but do nothing. They will be removed
as each of those layers is brought forward from py2k shiat into modern py3k.
Said another way; dear god, one can properly do interfaces now and isinstance
isn't
dog slow.
Signed-off-by: Brian Harring <ferringb <AT> gmail.com>
bin/pplugincache | 1 -
doc/man/pkgcore.rst | 384 ------------------------------------
doc/man/pmerge.rst | 50 -----
doc/man/pquery.rst | 81 --------
src/pkgcore/scripts/pplugincache.py | 34 ----
tests/scripts/test_pplugincache.py | 12 --
6 files changed, 562 deletions(-)
diff --git a/bin/pplugincache b/bin/pplugincache
deleted file mode 120000
index 6b4695d3..00000000
--- a/bin/pplugincache
+++ /dev/null
@@ -1 +0,0 @@
-../src/pkgcore/scripts/__init__.py
\ No newline at end of file
diff --git a/doc/man/pkgcore.rst b/doc/man/pkgcore.rst
deleted file mode 100644
index 1c79d0ba..00000000
--- a/doc/man/pkgcore.rst
+++ /dev/null
@@ -1,384 +0,0 @@
-=======
-pkgcore
-=======
-
-Description
-===========
-
-pkgcore is a framework for package management; via the appropriate class
-plugins, the design should allow for almost any underlying repository, config,
-or format to be used. However, it's currently focused on providing support for
-ebuilds and the Gentoo ecosystem in general.
-
-Portage Compatibility
-=====================
-
-In general, pkgcore tries to remain somewhat compatible with much of the
-current **portage**\(5) configuration.
-
-Missing or differing functionality
-----------------------------------
-
-The following is a list of semi-major portage features that currently do not
-have a pkgcore equivalent. Some of them are planned to be added in the future
-while others are not (and are noted as such).
-
-This section mostly serves as a warning for the unwary that might expect
-everything to operate in the same fashion when switching between package
-managers.
-
-* /etc/portage/repos.conf
-
- The only way to add repos to pkgcore is to use repos.conf, PORTDIR and
- PORTDIR_OVERLAY settings in **make.conf**\(5) are not respected anymore.
-
- In addition, not all fields that portage supports are used by pkgcore.
- Currently in repo sections the only supported fields are 'location',
- 'priority', 'sync-type', and 'sync-uri' while 'main-repo' is the only
- supported field in the default section. Support for more attributes will be
- added in the future, but pkgcore is unlikely to ever support the full set
- used by portage.
-
-* /etc/portage/make.conf
-
- Config values are only loaded from /etc/portage/make.conf, the deprecated
- /etc/make.conf location is not checked anymore.
-
-* dynamic deps
-
- Dependency data for installed packages is always pulled from the vdb which is
- only allowed to be altered on install and removed at uninstall. There is no
- plan to support retrieving updated dependency data from unbuilt ebuilds in
- source repositories and updating the vdb.
-
-FEATURES
---------
-
-Supported:
-
-* ccache
-* distcc
-* sandbox
-* usersandbox
-* userpriv
-* test
-* nodoc
-* noinfo
-* noman
-* userfetch (forced on)
-* usersync
-* collision-protect
-* metadata-transfer (does not do the actual transfer however)
-* nostrip
-
-Partially supported:
-
-* strict (mostly there, just missing a few additions)
-
-Unsupported digest-related:
-
-* assume-digests
-* cvs
-* digest
-
-Unsupported misc:
-
-* severe
-* keeptemp
-* keepwork
-* distlocks
-* selinux
-* sesandbox (selinux context sandbox)
-* fixpackages
-* notitles
-
-Unsupported, unlikely to be implemented:
-
-* noauto (too tool-specific)
-* mirror
-
- It's possible to implement it via a custom fetcher, but there are better
- ways; use ``mirror-dist`` if you want a mirror.
-
-* lmirror (same)
-* preserve-libs
-
- Libraries *are not* preserved when sonames change during upgrades or
- downgrades. This can easily render systems unworkable if major core system
- library changes occur. Users will have to make use of ``revdep-rebuild(1)``
from
- portage until an equivalent is added to pkgcore and/or support for preserved
- libs is added.
-
- Note that this also means there is no preserved-rebuild package set support
- either.
-
-Aside from that... everything else make.conf wise should be supported with
-out issue- if not, please open an issue.
-
-For ``/etc/portage/``, we don't support modules (define custom cache modules)
-due the fact our cache subsystem has grown a bit beyond what got imported into
-Portage in 2.1.
-
-For ``/etc/portage/package.*`` files, we support an extended atom syntax which
-can be used in place of normal atoms (It goes without saying Portage doesn't
-support the extension yet, thus introducing incompatibility if used) - read
-extended-atom-syntax.rst for the details.
-
-Configuration
-=============
-
-Note for Portage users
-----------------------
-
-If you already know how to configure Portage you can probably just skip this
-section. As long as you do not have an ``/etc/pkgcore/pkgcore.conf`` or
-``~/.config/pkgcore/pkgcore.conf`` pkgcore will read Portage's configuration
-files.
-
-Basics, querying
-----------------
-
-There are multiple ways to configure pkgcore. No matter which method you pick,
-the ``pconfig(1)`` utility will allow you to check if pkgcore interprets the
-configuration the way you intend. Part of a configuration dump could look
-like::
-
- $ pconfig dump
- <lots of output snipped>
-
- '/usr/local/portage/private' {
- # typename of this section: repo
- class pkgcore.ebuild.repository.UnconfiguredTree;
- # type: refs:cache
- cache {
- # typename of this section: cache
- class pkgcore.cache.flat_hash.database;
- <some stuff snipped>
- # type: str
- label '/usr/local/portage/private';
- # type: str
- location '/var/cache/edb/dep';
- };
- # type: list
- default_mirrors 'http://ftp.easynet.nl/mirror/gentoo//distfiles';
- # type: ref:eclass_cache
- eclass_cache 'eclass stack';
- # type: str
- location '/usr/local/portage/private';
- }
- <lots of output snipped>
-
-Starting at the top this means there is a "repo" known to pkgcore as
-"/usr/local/portage/private", of the class
-"pkgcore.ebuild.repository.UnconfiguredTree". The "repo" type means it
-is something containing packages. The "class" means that this
-particular repo contains unbuilt ebuilds. Below that are various
-parameters specific to this class. The "type" comment tells you how
-the argument is interpreted (this depends on the class).
-
-The first is "cache". This is a nested section: it defines a new
-object of the type "cache", class "pkgcore.cache.flat_hash.database".
-Below that are the parameters given to this cache class. It is import
-to understand that the ebuild repository does not care about the exact
-class of the cache. All it needs is one or more things of type
-"cache". There could have been some db-based cache here for example.
-
-The next argument to the repo is "default_mirrors" which is handled as
-a list of strings. "location" is a single string.
-
-"eclass_cache" is a section reference pointing to the named section
-"eclass stack" defined elsewhere in the dump (omitted here).
-
-If your configuration defines a section that does not show up in
-dump you can use ``uncollapsable`` to figure out why::
-
- $ pconfig uncollapsable
- Collapsing section named 'ebuild-repo-common':
- type pkgcore.ebuild.repository.UnconfiguredTree needs settings for 'location'
-
- Collapsing section named 'cache-common':
- type pkgcore.cache.flat_hash.database needs settings for 'label'
-
-Unfortunately the configuration system cannot distinguish between
-sections that are only meant as a base for other sections and actual
-configuration mistakes. The messages you see here are harmless. If you
-are debugging a missing section you should look for "Collapsing
-section named 'the-broken-section'" in the output.
-
-Portage compatibility mode
---------------------------
-
-If you do not have a global (``/etc/pkgcore.conf``) or local
-(``~/.pkgcore.conf``) configuration file pkgcore will automatically fall back
to
-reading ``/etc/portage/make.conf`` and the other Portage configuration files.
A
-noticable difference is pkgcore does not support picking up variables like USE
-from the environment, so you can't run commands like ``USE="foo" pmerge
-package``. Apart from that things should just work the way you're used to.
-
-Beyond Portage compatibility mode
----------------------------------
-
-Basics
-~~~~~~
-
-If you want to define extra repositories pkgcore should know about but Portage
-should not you will need a minimal configuration file. Pkgcore reads two
-configuration files: ``~/.pkgcore.conf`` and ``/etc/pkgcore.conf``. Settings
in
-the former override the ones in the latter.
-
-If one of them exists this completely disables Portage configuration file
-parsing. The first thing you will probably want to do is re-enable that, by
-putting in one of the configuration files::
-
- [autoload-portage]
- class=pkgcore.ebuild.portage_conf.config_from_make_conf
-
-If you then run ``pconfig dump`` you should see among other things::
-
- 'autoload-portage' {
- # typename of this section: configsection
- class pkgcore.ebuild.portage_conf.config_from_make_conf;
- }
-
-Section names are usually arbitrary but sections that load extra configuration
-data are an exception: they have to start with "autoload" or they will not be
-processed. If you change the section name to just "portage" you will still see
-it show up in ``pconfig dump`` but all other things defined in
-``/etc/portage/make.conf`` will disappear.
-
-``pconfig`` can tell you what arguments a class takes::
-
- $ pconfig describe_class pkgcore.config.basics.parse_config_file
- typename is configsection
-
- parser: callable (required)
- path: str (required)
-
-If you wanted to remove the overlay mentioned at the top of this document from
-``/etc/portage/make.conf`` but keep it available to pkgcore you would add::
-
- [/usr/local/portage/private]
- class=pkgcore.ebuild.repository.UnconfiguredTree
- cache=private-cache
- default_mirrors='http://ftp.easynet.nl/mirror/gentoo//distfiles'
- eclass_cache='eclass stack'
- location='/usr/local/portage/private'
-
- [private-cache]
- class=pkgcore.cache.flat_hash.database
- ; All the stuff snipped earlier
- label='/usr/local/portage/private'
- location='/var/cache/edb/dep'
-
-Because the ini file format does not allow nesting sections we had to
-put the cache in a named section and refer to that. The dump output
-will reflect this but everything else will work just like it did
-before.
-
-Inherits
-~~~~~~~~
-
-If you have a lot of those overlays you can avoid repeating the common
-bits::
-
- [stuff-common-to-repos]
- class=pkgcore.ebuild.repository.UnconfiguredTree
- default_mirrors='http://ftp.easynet.nl/mirror/gentoo//distfiles'
- eclass_cache='eclass stack'
- inherit-only=true
-
- [/usr/local/portage/private]
- inherit=stuff-common-to-repos
- location='/usr/local/portage/private'
- cache=private-cache
-
- [/usr/local/portage/other-overlay]
- inherit=stuff-common-to-repos
- location='/usr/local/portage/other-overlay'
- cache=other-overlay-cache
-
- ; And do the same thing for the caches.
-
-There is nothing special about sections used as target for "inherit".
-They can be complete sections, although they do not have to be. If
-they are not complete sections you should set inherit-only to true for
-them, to make pconfig uncollapsable ignore errors in them.
-
-Actually, the Portage emulation mode uses inherit targets too, so you
-could just have inherited "ebuild-repo-common". Inherit targets do not
-have to live in the same file as they are inherited from.
-
-One last special features: things marked as "incremental" get their
-inherited value appended instead of overriding it.
-
-Aliases
-~~~~~~~
-
-You may have seen something called "section_alias" in a Portage
-compatibility configuration. These are used to make an existing named
-section show up under a second name. You probably do not need them if
-you write your own configuration.
-
-Atom Syntax
-===========
-
-In addition to the atom specification enhancements defined in various supported
-EAPIs, pkgcore provides several syntax extensions mostly relating to globbing-
-examples are provided below.
-
-This form can be used in configuration files, but in doing so portage will have
-issues with the syntax. To maintain configuration compatibility, limit extended
-syntax usage to the commandline only.
-
-=====================
==========================================================
-Token Result
-=====================
==========================================================
-\* match anything
-portage package name must be ``portage``
-dev-util/* category must be ``dev-util``
-dev-\*/\* category must start with ``dev-``, any package name
-dev-util/* category must be ``dev-util``, any package
-dev-* package must start with ``dev-``, any category
-\*cgi* package name must have ``cgi`` in it
-\*x11*/X* category must have ``x11`` in it, package must start
with ``X``
-\*-apps/portage* category must end in ``-apps``, package must start with
``portage``
-dev-vcs/\*bzr*tools\* category must be dev-vcs, and the globbing there is like
- shell globbing (bzr and tools must be in the package
- name, and bzr must proceed tools)
-=portage-1.0 match version 1.0 of any 'portage' package
-=====================
==========================================================
-
-Utilities
-=========
-
-**pclonecache**\(1)
- clone a repository cache
-
-**pebuild**\(1)
- low-level ebuild operations, go through phases manually
-
-**pinspect**\(1)
- generic utility for inspecting repository related info
-
-**pmaint**\(1)
- generic utility for repository maintenance (syncing, copying...)
-
-**pmerge**\(1)
- generic utility for doing resolution, fetching, merging/unmerging, etc.
-
-**pquery**\(1)
- generic utility for querying info about repositories, revdeps, pkg search,
- vdb search, etc.
-
-Reporting Bugs
-==============
-
-Please submit an issue via github:
-
-https://github.com/pkgcore/pkgcore/issues
-
-See Also
-========
-
-**portage**\(5), **make.conf**\(5), **pclonecache**\(1), **pebuild**\(1),
-**pinspect**\(1), **pmaint**\(1), **pmerge**\(1), **pquery**\(1)
diff --git a/doc/man/pmerge.rst b/doc/man/pmerge.rst
deleted file mode 100644
index 1480df4e..00000000
--- a/doc/man/pmerge.rst
+++ /dev/null
@@ -1,50 +0,0 @@
-======
-pmerge
-======
-
-.. include:: pmerge/_synopsis.rst
-.. include:: pmerge/_description.rst
-
-Portage Compatibility
-=====================
-
-With regards to portage compatibility, pmerge provides much of the same
-functionality that **emerge**\(1) does. In general, it should be possible to
use
-both pmerge and emerge on the same system in a sane fashion. For example,
-pmerge can be used to install packages and then emerge should be able to
-upgrade or uninstall them, or vice versa. Also, binary packages created using
-pmerge should be able to be installed properly using emerge. Any major
-compatibility issue that arises when trying to use both package managers is
-probably a bug and should be reported.
-
-In terms of option naming, pmerge tries to remain somewhat compatible to
-portage so running ``pmerge -1av`` should work the same as ``emerge -1av`` when
-using portage. However, pmerge doesn't implement nearly the same amount of
-options that portage provides so many of the more obscure ones are missing. In
-addition, pmerge defaults to a portage compatible output format that closely
-matches the default colors and output structure that portage uses.
-
-.. include:: pmerge/_options.rst
-.. include:: pmerge/_subcommands.rst
-
-Example Usage
-=============
-
-Merge pkgcore from the gentoo repo::
-
- pmerge sys-apps/pkgcore::gentoo
-
-Output a simple list of package atoms that would be updated for a global
-update::
-
- pmerge -uDp --formatter basic @world
-
-Force new binpkgs to be built for the entire system set using a custom
-configuration directory::
-
- pmerge -uDSeb --config /home/foo/portage @system
-
-See Also
-========
-
-**emerge**\(1)
diff --git a/doc/man/pquery.rst b/doc/man/pquery.rst
deleted file mode 100644
index 83d2fffc..00000000
--- a/doc/man/pquery.rst
+++ /dev/null
@@ -1,81 +0,0 @@
-======
-pquery
-======
-
-.. include:: pquery/_synopsis.rst
-.. include:: pquery/_description.rst
-.. include:: pquery/_options.rst
-.. include:: pquery/_subcommands.rst
-
-Usage
-=====
-
-Another switch that could do with some extra explanation is ``--raw``.
-Specifying ``--raw`` makes your configuration not affect the results. Example::
-
- $ pquery --attr alldepends sys-apps/dbus --max -v
- * sys-apps/dbus-0.62-r1
- description: A message bus system, a simple way for applications to talk
- to each other
- homepage: http://dbus.freedesktop.org/
- depends: >=dev-libs/glib-2.6 || ( ( x11-libs/libXt x11-libs/libX11 )
- virtual/x11 ) >=x11-libs/gtk+-2.6 >=dev-lang/python-2.4
- >=dev-python/pyrex-0.9.3-r2 >=dev-libs/expat-1.95.8
- dev-util/pkgconfig sys-devel/automake
- >=sys-devel/autoconf-2.59 sys-devel/libtool
- rdepends: >=dev-libs/glib-2.6 || ( ( x11-libs/libXt x11-libs/libX11 )
- virtual/x11 ) >=x11-libs/gtk+-2.6 >=dev-lang/python-2.4
- >=dev-python/pyrex-0.9.3-r2 >=dev-libs/expat-1.95.8
- post_rdepends:
-
-This is the highest unmasked package on the system. Also notice there are no
-references to USE flags or qt in the dependencies. That is because qt is not in
-USE for this configuration, so those dependencies do not apply.::
-
- $ pquery --attr alldepends sys-apps/dbus --max -v --raw
- * sys-apps/dbus-0.91
- description: Meta package for D-Bus
- homepage: http://dbus.freedesktop.org/
- depends:
- rdepends: >=sys-apps/dbus-core-0.91 python? (
- >=dev-python/dbus-python-0.71 ) qt3? (
- >=dev-libs/dbus-qt3-old-0.70 ) gtk? (
- >=dev-libs/dbus-glib-0.71 ) !<sys-apps/dbus-0.91
- post_rdepends:
-
-This version is in ``package.mask``, and we can see the use-conditional flags
now.
-
-The ``--verbose`` or ``-v`` flag tries to print human-readable output (although
-some things like the formatting of depend strings need some improvement).
-Without ``-v`` the output is usually a single line per package in a hopefully
-machine-parseable format (usable in pipelines). There are some extras like
-``--atom`` meant for shell pipeline use. If you have some useful shell pipeline
-in mind that pquery's output could be better formatted for please open an
issue.
-
-Adding short options is planned but there are some features to add first (want
-most of the features in place to avoid name clashes).
-
-Examples
-========
-
-============================ =========================================
========================================================================
-Other tool pquery Comments
-============================ =========================================
========================================================================
-``equery belongs /bin/ls`` ``pquery --owns /bin/ls``
-``equery check`` not implemented (yet?)
-``equery depends python`` ``pquery -I --revdep dev-lang/python``
omitting ``-I`` makes it equivalent to ``equery depends -a``
-``equery depgraph`` not implemented (yet?)
-``equery files python`` ``pquery --contents python``
``--contents`` is an output option, can be combined with any restriction
-``equery hasuse python`` ``pquery -I --has-use python``
-``equery list python`` ``pquery -I '*python*'`` this is
in ExtendedAtomSyntax
-``equery size python`` ``pquery --size python``
-``equery uses python`` ``pquery --attr use python`` less
information, but is an output option so mixes with any restriction
-``emerge -s python`` ``pquery -vn '*python*'``
-``emerge -S python`` ``pquery -vnS python``
searches through longdescription (from metadata.xml) too
-no equivalent ``pquery --license GPL-2 -I`` list
all installed GPL-2 packages
-no equivalent ``pquery --maintainer radhermit`` list
all packages that are maintained by radhermit
-============================ =========================================
========================================================================
-
-It can also do some things equery/emerge do not let you do, like restricting
-based on maintainer or herd and printing various other package attributes. See
-``--help`` for those. If you miss a query open an issue.
diff --git a/src/pkgcore/scripts/pplugincache.py
b/src/pkgcore/scripts/pplugincache.py
deleted file mode 100644
index 09f54a7b..00000000
--- a/src/pkgcore/scripts/pplugincache.py
+++ /dev/null
@@ -1,34 +0,0 @@
-"""plugin cache update utility"""
-
-from functools import partial
-
-from snakeoil.sequences import stable_unique
-
-from .. import plugin, plugins
-from ..util import commandline
-
-argparser = commandline.ArgumentParser(
- config=False,
- domain=False,
- color=False,
- description=__doc__,
- script=(__file__, __name__),
-)
-argparser.add_argument(
- "packages",
- nargs="*",
- action="store",
- default=[plugins],
- type=partial(commandline.python_namespace_type, module=True),
- help="python namespace(s) to regenerate plugins for. If none are "
- "specified, pkgcore.plugins is updated",
-)
-
-
[email protected]_main_func
-def main(options, out, err):
- """Update caches."""
- for package in stable_unique(options.packages):
- if options.verbosity >= 0:
- out.write(f"updating cache: {package.__name__}")
- plugin.initialize_cache(package, force=True)
diff --git a/tests/scripts/test_pplugincache.py
b/tests/scripts/test_pplugincache.py
deleted file mode 100644
index 880a5eaa..00000000
--- a/tests/scripts/test_pplugincache.py
+++ /dev/null
@@ -1,12 +0,0 @@
-from pkgcore import plugins
-from pkgcore.scripts import pplugincache
-from pkgcore.test.scripts.helpers import ArgParseMixin
-
-
-class TestCommandline(ArgParseMixin):
- _argparser = pplugincache.argparser
-
- has_config = False
-
- def test_parser(self):
- assert self.parse().packages == [plugins]