[python] Look for django entrypoint from setting file's from sibling imports.#15354
[python] Look for django entrypoint from setting file's from sibling imports.#15354
Conversation
🦋 Changeset detectedLatest commit: 4153a3a The changes in this PR will be included in the next version bump. This PR includes changesets to release 17 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
📦 CLI Tarball ReadyThe Vercel CLI tarball for this PR is now available! Quick TestYou can test this PR's CLI directly by running: npx https://vercel-mwamt7gto.vercel.sh/tarballs/vercel.tgz --helpUse in vercel.jsonTo use this CLI version in your project builds, add to your {
"build": {
"env": {
"VERCEL_CLI_VERSION": "vercel@https://vercel-mwamt7gto.vercel.sh/tarballs/vercel.tgz"
}
}
}Python Runtime WheelA Python Workers WheelA |
🧪 Unit Test StrategyComparing: Strategy: Code changed outside of a package - running all unit tests Affected packages - 40 (100%)
Results
This comment is automatically generated based on the affected testing strategy |
|
This code all looks totally fine but I'm not sure that we actually want to do it. I think we are going to want to do dynamic analysis to recover the routes and stuff, and we might want to move the entrypoint detection into that when it is complicated. (I have something I'm working on that will start doing some dynamic analysis) |
msullivan
left a comment
There was a problem hiding this comment.
I think we should skip this and try a dynamic analysis instead
Instead of parsing the manage.py and the settings file, we instead *import* it with python and print out the globals in it. To find the settings file, we run `manage.py` with a monkeypatch. This will handle some stuff like sibling imports (`from .common import *`, discussed in #15354) that we don't handle now, and will provide a framework for handling other dynamic stuff as well. I've pulled out some of the existing django identification stuff. <!-- VADE_RISK_START --> > [!NOTE] > Low Risk Change > > This PR replaces static AST-based Django settings parsing with dynamic Python execution that imports and runs manage.py, which introduces potential code execution risks during build but is a refactor of existing build-time behavior rather than a security control change. > > - New dynamic Django settings discovery executes Python code via `execa('python', ['-c', script])` > - Removes static AST parsing functions (`parseDjangoSettingsModule`, `getDjangoEntrypoint`) in favor of runtime imports > - Adds Python script that monkeypatches Django and runs `manage.py` to extract settings > > <sup>Risk assessment for [commit 41ffba8](https://github.com/vercel/vercel/commit/41ffba8d4062b6ec1d68cc450b422cf88732d46a).</sup> <!-- VADE_RISK_END --> --------- Co-authored-by: vercel[bot] <35613825+vercel[bot]@users.noreply.github.com>
A common pattern is:
hello/settings/dev.py:hello/settings/common.pyNote
Low Risk Change
This PR adds a new feature to follow sibling imports when looking for Django entrypoints, consisting of new Rust parsing logic, TypeScript wrappers, and comprehensive tests with no security, auth, or schema changes.
getStringConstantOrImportfunction in Rust/TS to follow sibling importsgetDjangoEntrypointto check sibling settings files one level deepRisk assessment for commit 4153a3a.