4a9e30bc86
We'd like to run our executable python scripts using our new `pywrap`
feature as a better way to get their PYTHONPATH setup properly. This
script lives in our source tree, at a fixed relative location to each
script that we're interested in, but has no absolute system path.
The #!interpreter syntax does supports relative paths, but they are
resolved relative to the current working directory, not relative to the
file in which they appear, which makes this feature pretty useless.
There are some tricks we can do to get our designed 'relative'
behaviour, though.
Something like this works:
#!/usr/bin/env -S sh -c '"${0%/*}/pywrap" "$0"'
but it causes various file auto-detection schemes (including our own
test/static-code) to improperly conclude that this is a shell script,
rather than a Python script. (n)vim also gets it wrong for highlighting
and linting purposes.
Fortunately there's a somewhat longer, but still acceptable version of
this we can do in Python:
#!/usr/bin/python3 -cimport os, sys; os.execv(os.path.dirname(sys.argv[1]) + "/pywrap", sys.argv)
This fits well under our 118 column limit.
Note that unlike `sh`, the `-c` option in Python doesn't require the
script to be passed as a separate argument, which means we don't need to
use the non-POSIX splitting tricks of `/usr/bin/env -S`.
Note also: it appears as though our hardcoding of /usr/bin/python3 here
might be venv-unfriendly, but it's not: /usr/bin/python3 (which surely
exists) is used only for running this one tiny fragment of code. Our
pywrap script itself finds python3 in the path.
Let's move all of our previous users of `import parent` over to the new
approach.
We can remove a couple of `parent.py` symlinks we had lying
around, as well.
We also remove `parent.py` itself, since otherwise vulture complains
about it being unused. Subprojects will be forced to adjust on upgrade.
Remove a CodeQL exemption that was necessitated by our `import parent`
shenanigans.
|
||
|---|---|---|
| .cockpit-ci | ||
| .fmf | ||
| .github | ||
| containers | ||
| doc | ||
| examples | ||
| modules | ||
| node_modules@055682f225 | ||
| pkg | ||
| plans | ||
| po | ||
| selinux | ||
| src | ||
| test | ||
| tools | ||
| .eslintignore | ||
| .eslintrc.json | ||
| .flake8 | ||
| .flowconfig | ||
| .gitignore | ||
| .gitleaks.toml | ||
| .gitmodules | ||
| .stylelintrc.json | ||
| AUTHORS | ||
| COPYING | ||
| HACKING.md | ||
| Makefile.am | ||
| README.md | ||
| autogen.sh | ||
| build.js | ||
| configure.ac | ||
| files.js | ||
| package.json | ||
| packit.yaml | ||
| pyproject.toml | ||
README.md
Cockpit
A sysadmin login session in a web browser
Cockpit is an interactive server admin interface. It is easy to use and very lightweight. Cockpit interacts directly with the operating system from a real Linux session in a browser.
Using Cockpit
You can install Cockpit on many Linux operating systems including Debian, Fedora and RHEL.
Cockpit makes Linux discoverable, allowing sysadmins to easily perform tasks such as starting containers, storage administration, network configuration, inspecting logs and so on.
Jumping between the terminal and the web tool is no problem. A service started via Cockpit can be stopped via the terminal. Likewise, if an error occurs in the terminal, it can be seen in the Cockpit journal interface.
You can also easily add other machines that have Cockpit installed and are accessible via SSH and jump between these hosts.