A shared notebook should carry its package requirements
marimo's inline requirements make a notebook easier to hand over. Separate that package contract from the data, system libraries and credentials it still needs.
By 
Paul. Languages and frameworks
A notebook passed to another person should carry an explicit account of the packages it needs. Otherwise the recipient inherits a detective job before reaching the analysis. Keeping those requirements in the notebook can make a small handoff much clearer. It cannot, by itself, preserve the data and operating environment that produced the result.
marimo's September 2024 package feature is useful at that particular boundary: sharing one analysis artifact. Looking back from November 2026, the durable argument is for making the notebook's requirements travel with it while stating what remains outside. A portable file and a fully repeatable experiment are different deliverables.
What the announcement established
The marimo announcement of 16 September 2024 describes package requirements stored in a top-level comment in its Python notebook file. Its opt-in sandbox uses uv to create an isolated virtual environment and install the declared dependencies. The post also describes tracking imports to help maintain those declarations.
The underlying PEP 723 specification defines inline script metadata, including dependency declarations and a Python version requirement. Its creation date is 4 August 2023, with a resolution dated 8 January 2024. September's notebook feature used an existing standard; it did not introduce that standard.
The mechanism puts environment information beside the code a recipient receives. Isolation helps distinguish declared requirements from packages that happened to be installed on the author's machine. It is package-environment isolation, not a claim that arbitrary notebook code is safe to execute or unable to access files and networks.
The missing attachment is a design problem
Consider an illustrative analyst sending a notebook to a colleague who must check a proposed forecast. If the analysis file arrives without its separately maintained requirements file, the colleague has to discover what was omitted. Even a correct dependency file is ineffective when the normal sharing action leaves it behind.
Embedding the declaration changes that handoff. The analysis and its package requirements share one file, so sending the analysis also sends that part of its operating contract. That is a practical improvement independent of any claim about installation speed. No installation timing or recipient study was conducted for this article.
The contract still needs inspection. A list of direct dependencies can be incomplete, and broad version ranges can permit different resolved environments later. Pinning direct versions narrows the possibilities without necessarily fixing every transitive dependency. Where exact reconstruction matters, identify the additional resolution record and retention policy the team will use. Do not label a declaration a complete lock merely because it contains version numbers.
Data has its own history
A notebook can install successfully and produce a different answer because its input changed. A live query may now include another month of transactions. A remote file may have been replaced at the same address. Neither situation is solved by putting package names in the notebook.
For an important handoff, describe the input dataset, the relevant time boundary and the revision or snapshot used. State whether the recipient is meant to reproduce an earlier result or rerun the analysis on current data. Both are legitimate tasks, but they have different acceptance criteria. A changed total may be expected in the second and a failure in the first.
Keep permissions separate from descriptions. The notebook should explain how an authorized recipient obtains the necessary input without embedding secrets in a file that may be forwarded. If access cannot be granted, an approved sample dataset may allow review of the method while leaving the original result unverified. Label that limit explicitly.
A virtual environment leaves other dependencies outside
Python packages are only part of a working environment. An analysis may rely on an operating-system library, an external executable or a service endpoint. Hardware-sensitive calculations and random inputs can introduce other sources of variation. The package declaration does not establish control over all of them.
Record the outside requirements that actually affect the task. For a simple local analysis, a short note may be enough. For a regulated or long-lived result, the required evidence may be much more demanding and should be specified by the responsible organization. This article does not establish that a notebook format satisfies such obligations.
The useful scope is explicit rather than maximal. A recipient checking a chart's grouping logic may not need an exact historical machine image. A recipient investigating why last year's number changed may need retained inputs and a more tightly recorded environment. Decide which question the handoff is meant to answer before choosing the preservation effort.
A repository-level environment can be the better contract
The strongest counterargument is a team maintaining many related notebooks with shared libraries. Separate per-notebook declarations can drift and obscure the fact that the analyses form one maintained project. A repository-level environment may make updates and coordinated review easier.
That is a reason to choose the unit of ownership deliberately. If notebooks travel independently, local declarations can fit the sharing pattern. If they depend on common internal code and are always reviewed together, the repository may be the honest delivery unit. Sending a single file should not pretend to deliver a project that requires the rest of the repository.
Avoid forcing both models on the same work without deciding which record governs. A stale inline list and a current project environment leave the recipient with competing instructions. Document the supported way to open and run the artifact, then maintain that route when dependencies change.
Make the recipient's task the acceptance test
A useful handoff asks an authorized recipient to open the artifact in the intended clean environment, obtain the specified input and complete the agreed check. Record missing requirements and unexplained differences. This is a proposed acceptance exercise, not a test performed on marimo here.
For a custom software or analysis tool, define what the recipient must be able to repeat and what remains outside the deliverable. marimo's September feature brought the package contract closer to the analysis. A responsible handoff also tells the next person where that contract ends.