plesty.server.reexec
====================

.. py:module:: plesty.server.reexec

.. autoapi-nested-parse::

   How ``plesty-server`` starts another copy of itself.

   Jobs and the detached launcher are ``plesty-server`` processes too. From a
   source checkout that is ``python -m plesty.server …``; inside a PyInstaller
   bundle there is no interpreter to give ``-m`` to — ``sys.executable`` *is*
   ``plesty-server``, and the same arguments go straight to it. This module is
   the one place that knows the difference, so nothing else asks ``sys.frozen``.



Attributes
----------

.. autoapisummary::

   plesty.server.reexec.CONSOLE_EXECUTABLE


Functions
---------

.. autoapisummary::

   plesty.server.reexec.frozen
   plesty.server.reexec.program
   plesty.server.reexec.console_interpreter
   plesty.server.reexec.self_command
   plesty.server.reexec.launcher_command
   plesty.server.reexec.describe


Module Contents
---------------

.. py:data:: CONSOLE_EXECUTABLE
   :value: 'plesty-server'


.. py:function:: frozen() -> bool

   Whether this process runs from a PyInstaller bundle.


.. py:function:: program() -> str

   The executable that runs ``plesty-server`` commands.

   In a bundle that is the console executable beside ``sys.executable`` —
   never ``sys.executable`` itself, which may be the windowed
   ``plesty-server-gui`` whose entry point turns every invocation into
   ``gui``. From source it is the interpreter.


.. py:function:: console_interpreter() -> str

   The interpreter that can own a console: ``python.exe``, never ``pythonw.exe``.

   Windows gives a console only to a **console-subsystem** program, so
   ``CREATE_NEW_CONSOLE`` is a no-op for ``pythonw.exe`` — a windowed process
   asks for a console and gets nothing. Its console-subsystem child then finds
   no console to inherit and Windows gives that one a new, *visible* console:
   a terminal in front of the operator every time a device server starts.
   Under the Qt console ``sys.executable`` **is** ``pythonw.exe``, so anything
   that re-executes us must ask for its console-owning twin. The same
   reasoning as :func:`program`, one level down.


.. py:function:: self_command(*args: str) -> list[str]

   The command line that runs ``plesty-server <args>`` with this same program.

   :param args: Arguments for ``plesty-server``.


.. py:function:: launcher_command() -> list[str]

   The command line that starts the detached launcher (see ``services.launch``).

   From source it is the launch module itself, so the waiter stays a small
   process that never imports click; in a bundle it is the hidden
   ``_launch`` command of the one executable there is. Either way it is the
   **console** program: the waiter owns the hidden console its children
   inherit, and a windowed one cannot (:func:`console_interpreter`).


.. py:function:: describe(argv: collections.abc.Sequence[str]) -> str

   One line saying how *argv* will be run (for logs).