Working with external surrounding project deps (with sandbox?) #3008
Labels
documentation
Improvements or additions to documentation
Comments
gabrielgrant
changed the title
|
We don't currently don't support this today. Maybe there is some magic we could do with uv's dependency groups. The best workaround today would be calling Another option is maybe marimo can ship |
|
got part way there with: import subprocess
import shutil
poetry_bin = shutil.which('poetry')
poetry_export = subprocess.Popen(
[poetry_bin, "export", "--without-hashes", "--with", "dev", "-f", "requirements.txt"],
stdout=subprocess.PIPE,
env={"POETRY_WARNINGS_EXPORT": "false"}
)
uv_bin = shutil.which('uv')
subprocess.run(
[uv_bin, "pip", "install", "--no-deps", "-r", "/dev/stdin"],
stdin=poetry_export.stdout,
check=True,
)
poetry_export.stdout.close()
poetry_export.wait()(based loosely on https://mil.ad/blog/2024/uv-poetry-install.html ) that seems to install the packages into the sandbox: but then fails with a bunch of marimo errors that seem to be related to reloading: |
|
@gabrielgrant - does it work if you turn off module reloading? Its on the footer, there is: on, lazy, off. |
|
the cell with the install code only shows the error the first time it is run after starting the kernel (after that it is just |
|
Oh, actually I misspoke: I had been re-launching the server in its entirety before (so recreating a new sandbox), not just restarting the kernel. Just restarting the kernel (with module change tracking turned off) actually does seem to work! |
|
Unfortunately this workaround seems to no longer be working as of 0.10.9 (I believe it was still working on 0.10.5). Still looks like the A quick glance thru the release notes doesn't point to any obvious changes to dep handling that would have affected this. (the only one that seems maybe semi-relevant is #3291 , but only tangentially so). Any idea what might have changed? |
|
Could your |
|
Thanks for the follow-up. It seems the issue was related to a python upgrade detailsdefault had been updated in one branch of the parent repo but hadn't in another, so switching between was causing issues where the deps were being installed in the wrong place/by the wrong python. Didn't totally track down all the details of what was going wrong, but rebasing to stop the swapping between default py versions seems to have fixed it. So the workaround install code i posted above is working again |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Documentation is
Explain in Detail
We work with notebooks within a larger project. Marimo is ideal for this, since it doesn't cause the horrendous diffs we get from Jupyter.
The outer project is managed with poetry. We don't want marimo in the general project deps, and sometimes want additional tools in a notebook for testing/analysis that aren't in project deps. Not finding docs on a good workflow for this
So far been trying out the VSCode extension and pointing it at a separate python venv with marimo installed, then manually adding the project dir to the path within the notebook. This kinda works for simple things, but is fragile and doesn't have project-specific deps. Would be ideal if a workflow/solution would work with the VSCode extension, but not a requirement
Your Suggestion for Changes
It would be great to be able to have the project deps installed and then any notebook-specific deps layered on top all in a single sandbox. Not sure if that's achievable today? Maybe with uv directly? However it's best done, this general pattern of having some notebooks for doing exploratory work within a larger project repo seems like a common patter that it'd be great to see addressed in the docs
The text was updated successfully, but these errors were encountered: