Send patches - preferably formatted by git format-patch - to patches at archlinux32 dot org.
summaryrefslogtreecommitdiff
path: root/docs/archinstall
diff options
context:
space:
mode:
Diffstat (limited to 'docs/archinstall')
-rw-r--r--docs/archinstall/Application.rst10
-rw-r--r--docs/archinstall/Profile.rst16
-rw-r--r--docs/archinstall/general.rst117
-rw-r--r--docs/archinstall/plugins.rst57
4 files changed, 57 insertions, 143 deletions
diff --git a/docs/archinstall/Application.rst b/docs/archinstall/Application.rst
deleted file mode 100644
index c6eb0d4d..00000000
--- a/docs/archinstall/Application.rst
+++ /dev/null
@@ -1,10 +0,0 @@
-.. _archinstall.Application:
-
-archinstall.Application
-=======================
-
-This class enables access to pre-programmed application configurations.
-This is not to be confused with :ref:`archinstall.Profile` which is for pre-programmed profiles for a wider set of installation sets.
-
-
-.. autofunction:: archinstall.Application
diff --git a/docs/archinstall/Profile.rst b/docs/archinstall/Profile.rst
deleted file mode 100644
index a4c1f3bb..00000000
--- a/docs/archinstall/Profile.rst
+++ /dev/null
@@ -1,16 +0,0 @@
-.. _archinstall.Profile:
-
-archinstall.Profile
-===================
-
-This class enables access to pre-programmed profiles.
-This is not to be confused with :ref:`archinstall.Application` which is for pre-programmed application profiles.
-
-Profiles in general is a set or group of installation steps.
-Where as applications are a specific set of instructions for a very specific application.
-
-An example would be the *(currently fictional)* profile called `database`.
-The profile `database` might contain the application profile `postgresql`.
-And that's the difference between :ref:`archinstall.Profile` and :ref:`archinstall.Application`.
-
-.. autofunction:: archinstall.Profile
diff --git a/docs/archinstall/general.rst b/docs/archinstall/general.rst
deleted file mode 100644
index 970d40f2..00000000
--- a/docs/archinstall/general.rst
+++ /dev/null
@@ -1,117 +0,0 @@
-.. _archinstall.helpers:
-
-.. warning::
- All these helper functions are mostly, if not all, related to outside-installation-instructions. Meaning the calls will affect your current running system - and not touch your installed system.
-
-Profile related helpers
-=======================
-
-.. autofunction:: archinstall.list_profiles
-
-Packages
-========
-
-.. autofunction:: archinstall.find_package
-
-.. autofunction:: archinstall.find_packages
-
-Locale related
-==============
-
-.. autofunction:: archinstall.list_keyboard_languages
-
-.. autofunction:: archinstall.search_keyboard_layout
-
-.. autofunction:: archinstall.set_keyboard_language
-
-..
- autofunction:: archinstall.Installer.set_keyboard_layout
-
-Services
-========
-
-.. autofunction:: archinstall.service_state
-
-Mirrors
-=======
-
-.. autofunction:: archinstall.filter_mirrors_by_region
-
-.. autofunction:: archinstall.add_custom_mirrors
-
-.. autofunction:: archinstall.insert_mirrors
-
-.. autofunction:: archinstall.use_mirrors
-
-.. autofunction:: archinstall.re_rank_mirrors
-
-.. autofunction:: archinstall.list_mirrors
-
-Disk related
-============
-
-.. autofunction:: archinstall.BlockDevice
-
-.. autofunction:: archinstall.Partition
-
-.. autofunction:: archinstall.Filesystem
-
-.. autofunction:: archinstall.device_state
-
-.. autofunction:: archinstall.all_blockdevices
-
-Luks (Disk encryption)
-======================
-
-.. autofunction:: archinstall.luks2
-
-Networking
-==========
-
-.. autofunction:: archinstall.get_hw_addr
-
-.. autofunction:: archinstall.list_interfaces
-
-.. autofunction:: archinstall.check_mirror_reachable
-
-.. autofunction:: archinstall.update_keyring
-
-.. autofunction:: archinstall.enrich_iface_types
-
-.. autofunction:: archinstall.get_interface_from_mac
-
-.. autofunction:: archinstall.wireless_scan
-
-.. autofunction:: archinstall.get_wireless_networks
-
-General
-=======
-
-.. autofunction:: archinstall.log
-
-.. autofunction:: archinstall.locate_binary
-
-.. autofunction:: archinstall.SysCommand
-
-.. autofunction:: archinstall.SysCommandWorker
-
-Exceptions
-==========
-
-.. autofunction:: archinstall.RequirementError
-
-.. autofunction:: archinstall.DiskError
-
-.. autofunction:: archinstall.ProfileError
-
-.. autofunction:: archinstall.SysCallError
-
-.. autofunction:: archinstall.ProfileNotFound
-
-.. autofunction:: archinstall.HardwareIncompatibilityError
-
-.. autofunction:: archinstall.PermissionError
-
-.. autofunction:: archinstall.UserError
-
-.. autofunction:: archinstall.ServiceException
diff --git a/docs/archinstall/plugins.rst b/docs/archinstall/plugins.rst
new file mode 100644
index 00000000..898f9006
--- /dev/null
+++ b/docs/archinstall/plugins.rst
@@ -0,0 +1,57 @@
+.. _archinstall.Plugins:
+
+Python Plugins
+==============
+
+``archinstall`` supports plugins via two methods.
+
+First method is directly via the ``--plugin`` parameter when running as a CLI tool. This will load a specific plugin locally or remotely via a path.
+
+The second method is via Python's built in `plugin discovery`_ using `entry points`_ categorized as ``archinstall.plugin``.
+
+``--plugin`` parameter
+----------------------
+
+The parameter has the benefit of being stored in the ``--conf`` state, meaning when re-running an installation — the plugin will automatically be loaded.
+It's limitation is that it requires an initial path to be known and written and be cumbersome.
+
+Plugin Discovery
+----------------
+
+This method allows for multiple plugins to be loaded with the drawback that they have to be installed beforehand on the system running ``archinstall``.
+This mainly targets those who build their own ISO's and package specific setups for their needs.
+
+
+What's supported?
+-----------------
+
+Currently the documentation for this is scarse. Until that is resolved, the best way to find supported features is to search the source code for `plugin.on_ <https://github.com/search?q=repo%3Aarchlinux%2Farchinstall+%22plugin.on_%22&type=code>`_ as this will give a clear indication of which calls are made to plugins.
+
+How does it work?
+-----------------
+
+``archinstall`` plugins use a discovery-driven approach where plugins are queried for certain functions.
+As an example, if a plugin has the following function:
+
+.. code-block:: python
+
+ def on_pacstrap(*packages):
+ ...
+
+The function :code:`archinstall.Pacman().strap(["some packages"])` is hardcoded to iterate plugins and look for :code:`on_pacstrap` in the plugin.
+If the function exists, :code:`.strap()` will call the plugin's function and replace the initial package list with the result from the plugin.
+
+The best way to document these calls is currently undecided, as it's hard to document this behavior dynamically.
+
+Writing your own?
+-----------------
+
+The simplest way currently is to look at a reference implementation or the community. Two of these are:
+
+* `torxed/archinstall-aur <https://github.com/torxed/archinstall-aur>`_
+* `phisch/archinstall-aur <https://github.com/phisch/archinstall-aur>`_
+
+And search for `plugin.on_ <https://github.com/search?q=repo%3Aarchlinux%2Farchinstall+%22plugin.on_%22&type=code>`_ in the code base to find what ``archinstall`` will look for. PR's are welcome to widen the support for this.
+
+.. _plugin discovery: https://packaging.python.org/en/latest/specifications/entry-points/
+.. _entry points: https://docs.python.org/3/library/importlib.metadata.html#entry-points \ No newline at end of file