Commit Graph

4 Commits (pbarnett/update-script-to-dockerhub)

Author SHA1 Message Date
Jamie Strandboge 941e0e0f15
fix: updates for package validation with portable glibc builds (#26131)
* fix(circleci): add librt.so to list of acceptable libraries

* feat(circleci): check for glibc portability

* fix(circleci): remove rpm --nodeps workaround in rpm validate

Now that we have glibc portability in rpm builds, we no longer need the
'rpm --nodeps' workaround and can go back to 'yum localinstall'.

Closes #26011

* chore: update README_processing_engine.md for glibc portability
2025-03-13 12:25:31 -05:00
Jackson Newhouse 5fa417c3f0
feat: remove system-py (#26087)
* feat: remove system-py

* chore: allow Apache-2.0 WITH LLVM-exception license.
2025-03-10 11:10:33 -07:00
Jamie Strandboge aa09d761a0
chore: clean up runtime code for python setup (#26042)
* chore: clean up runtime code for python setup

ccd5d22aab introduced working but temporary code for setting up the
python runtime environment. This cleans that up:

* refactor various find_python() functionality into virtualenv.rs
* refactor PYTHONHOME calculation to virtualenv.rs:find_python_install()
* adjust init_pyo3() to temporarily set PYTHONHOME based on
  virtualenv.rs:find_python_install() as this is the only place it is
  needed (indeed, venv activation scripts try to remove it)

Importantly, virtualenv.rs:find_python_install() tries to find the
python build standalone runtime based on a few heuristics. This function
could be improved in the fullness of time to, eg, be configured via a
build parameter.

Also, virtualenv.rs:find_python() can be used pre and post venv
activation. Before entering the venv, it will use find_python_install()
which is useful for things like setting up the initial venv. After
entering the venv, it will honor VIRTUAL_ENV (as set by
virtualenv.rs:initialize_venv()) to find python, which is important for
install packages with pip and having them installed into the venv.

* chore: update README_processing_engine.md for default venv

* chore: add bug reference for venv migrations with python minor releases

* chore: add security URLs to README_processing_engine.md

* chore: find_python_home() returns Option<PathBuf>. Thanks Jackson Newhouse

* fix: manually set sys.prefix, exec_prefix and sys.path

When activating a venv in the shell, sys.base_prefix and
sys.base_exec_prefix should be set to the installation location while
sys.prefix and sys.exec_prefix should be set to the venv dir.
Unfortunately, when initialize_venv() and init_pyo3() are called, we
can't use Py_InitializeFromConfig() to set any of these and certain
platforms are unable to find python-build-standalone. For now, we'll
temporarily set PYTHONHOME in init_pyo3() to the installation location
to make python work. By setting it at this point in the code, sys.prefix
and sys.exec_prefix end up also being set to the installation location,
which is fine when not under a venv, but is different from when entering
an venv.

To address this, in PYTHON_INIT.call_once() and when VIRTUAL_ENV is set
(which initialize_venv() will have set at this point), manually set
sys.prefix and sys.exec_prefix to what is in VIRTUAL_ENV.

Similarly, when activating a venv in the shell, sys.path is appended to
have the venv's site-packages dir. Previously we were setting PYTHONPATH
in initialize_venv() which ensures that the venv's site-packages dir is
in sys.path, but this ends up having the venv's site-packages dir first
in sys.path. To correct this, don't set PYTHONPATH any more and instead
adjust PYTHON_INIT.call_once() to append the venv's site-packages dir to
sys.path when VIRTUAL_ENV is set.

Finally, when exiting init_pyo3(), unconditionally unset PYTHONHOME when
VIRTUAL_ENV is set (like activation scripts do) and restore/unset when
it isn't.

Prior to these changes, all target incorrectly had the venv's
site-packages first in sys.path and OSX and Windows additionally had an
incorrect sys.prefix and sys.exec_prefix. With these initialization
changes in place, the runtime environment for the plugins is much closer
to that of a shell activated venv.
2025-02-26 12:06:23 -06:00
Jamie Strandboge ccd5d22aab
feat: build and use python-build-standalone with official builds (#25969)
* feat(ci): fetch and configure for python-build-standalone binaries

* fix: make the process engine usable on windows

* feat(ci): build with python-build-standalone (and drop musl)

* fix(ci): set rpath on Linux and libpath on OSX in ci

* fix: set PYTHONHOME everywhere and PYTHONPATH on Windows

* chore(ci): update to use more recent ci-packager-next

* fix(ci): adjust validate to allow certain dynamically linked libraries

* chore: remove install_influxdb.sh (using install_influxdb3.sh instead)

* chore(install_influxdb3.sh): update for processing engine and release builds

* fix: temporarily use rpm --nodeps until compile with old GLIBC

* feat(ci): build docker with python-build-standalone

* chore: add README_processing_engine.md

* chore: add a few more details to README_processing_engine.md

* fix(ci): use patchelf --set-rpath

Not all patchelf versions support --add-rpath for appending to the
RPATH, but --set-path can be used with a colon-separated list. Use
--set-rpath first for maximum compatibility.

* chore: update README_processing_engine.md for standalone local builds

* fix(Dockerfile): also use patchelf --set-rpath

* chore: update code comment for accuracy

* chore: typos, grammar and formatting change in README_processing_engine.md

* chore: update README_processing_engine.md for Docker arm64 (thanks Jackson)
2025-02-13 16:16:05 -06:00