Superset Dev
e053b6d92d
The oceanbase driver install step reported success but never actually installed oceanbase_py: --no-deps applied to `-e .[oceanbase]` blocks pip from installing anything the extras marker pulls in, including oceanbase_py itself, not just its conflicting transitive dependency. Installing oceanbase_py as its own standalone package instead means --no-deps only skips *its* dependencies, which is what was actually intended. Confirmed via a manual workflow_dispatch run (nightly_only dialects don't run on pull_request, so this needed a manual trigger to catch at all). Vertica dropped from this PR: the same workflow_dispatch run found `vertica/vertica-ce` doesn't exist on Docker Hub. The only actively maintained official image (`opentext/vertica-k8s`) is built to run under the Vertica Kubernetes operator's orchestration, not as a standalone single-container database -- a bare `docker run` likely won't bootstrap a working instance on its own. Needs real investigation before it's worth another attempt, same as Solr/IoTDB/TDengine/Parseable/Dremio earlier in this series.
Python dependency logic
In this folder, the .in files, in conjunction with the ../pyproject.toml file (in the root of the repo) are used to generate the pinned requirements as .txt files.
To alter the pinned dependency, you can edit/alter the .in and pyproject.toml files, and then run the following command:
./scripts/uv-pip-compile.sh
:::warning
The pinned dependencies are based on the current version of python supported in Superset.
Output of ./scripts/uv-pip-compile.sh may vary slightly based on the python version you are using to run the command.
Check the pyproject.toml file for the current version of python supported.
:::
This will generate the pinned requirements in the .txt files, which will be used in our CI/CD pipelines and in the Docker images.
We recommend to everyone in the community to use the pinned requirements in their local development environments, to ensure consistency across different environments, though we don't force requirements as part of our python package semantics to allow flexibility for users to install different versions of the dependencies if they wish.
Note that development.txt is a superset of what's in base.txt, and all version numbers for shared library should fully match at all times. translations.txt is meant as a supplemental file to be used in conjunction with the other requirements files, and is not meant to be used standalone.