Python Package Development for R Developers (Episode 2!) | R bloggers

Python Package Development for R Developers (Episode 2!) | R bloggers

[This article was first published on Yohann’s blog, and kindly contributed to R-bloggers]. (You can report a problem with the content on this page here)


Want to share your content on R bloggers? click here if you have a blog, or here if you don’t.

In a previous articleI shared my experience as an R developer delving into Python package development!

I had noticed several aspects that felt less smooth than in R, or even missing altogether!

Community feedback has helped me identify some resources that can help address the frustrations I initially encountered!

I showed that loading modules automatically was a bit more complicated in Python than in R. While this worked fine in development mode uv pip install -e .I found it more cumbersome when working in notebooks (especially Quarto).

To reproduce pkgload::load_all() behavior, I explored two options: automatic reloading in Quarto and Marimo.

Quarto

By adding a specific code snippet to the beginning of my notebook, I was able to work around the problem!

%load_ext autoreload
%autoreload 2

This option automatically reloads imported Python modules when you change their source code. This is a small difference compared to pkgload::load_all() in R, which will reload all modules in the current environment.

The parameter 2 means that all imported modules are automatically reloaded, except those in system packages.

For more information, please visit the official IPython documentation.

Marimo

This was the big discovery after my article! 😍

Marimo is a Python framework for building interactive and reproducible notebooks, and it feels surprisingly smooth to use. It feels a bit like a mix between Quarto and Shiny in the R world. Like Shiny, it is reactive: when you change an input or a variableeverything that depends on it is automatically updated. And like Quarto, it’s designed to combine code, text, and imagery into a single, shareable document. The result is a clean, self-contained environment where you can explore data, build small apps, or publish interactive reports, all without leaving Python.

The result is beautiful and the development experience is really enjoyable!

Most importantly, going back to my original problem: it automatically reloads imported modules when you change their source code!

The documentation is available for more information here.

To manage automatic reloading there is a parameter that you can enable in Marimo’s options, see the dedicated documentation here.

To install it with uvsimply run:

uv add "marimo[recommended]"

Quick reminder: uv add adds the package to your dependencies (in pyproject.toml) and installs it automatically.

And then to create/edit a notebook, just run:

uv run marimo edit path_to_your_notebook.py

And that’s it!


quartodoc This allows you to generate documentation as a website, just like {pkgdown} in R.

quartodoc extracts docstrings to generate .qmd or .md files, which Quarto can then display as static documentation sites.

I haven’t researched the tool in detail; it seems like more work than anything {pkgdown} required in R (which, let’s admit it, makes our lives much easier), but the output is frankly impressive and can look exactly like this {pkgdown}.

The documentation provides a fairly extensive video tutorial.


I found it difficult to find a tool that would allow me to check the quality of my code and documentation. devtools::check() sometimes we pull our hair out, but it’s really useful!

In the end, two tools were suggested to me: pre-record And ruff.

pre-record

pre-commit manages hooks that automatically perform checks before each commit, allowing you to enforce consistent formatting and code quality. It is very useful to avoid formatting errors, documentation problems, etc.

To install it with uvsimply run:

uv add pre-commit

After the minimal example of the documentation page I was able to create a .pre-commit-config.yaml file that checks the quality of my code and documentation with every commit.

You can also activate these controls manually (kind of like devtools::check() in R) with:

uv run pre-commit run --all-files

ruff

ruff acts as both linter and formatter, similar to how lintr and styler (or Air) complement each other in R.

For more information, see the ruff documentation.

As usual, installation with UV:

uv add ruff

Two commands are then available:

uv run ruff format .

And

uv run ruff check .

The first command formats the code, the second checks the code quality, which complements pre-commit (you can also configure pre-commit run ruff automatically on every commit by adding a hook to your .pre-commit-config.yaml file).


Conclusion

With the help of the community, I was able to identify tools that addressed the frustrations I initially encountered!

I was able to find essentially all the features I appreciate in R within Python! My favorite discovery is Marimo, which allows me to develop interactive notebooks in a very simple and efficient way!

The only remaining drawback is the {pkgdown} Equivalent: While it can produce beautiful sites, it feels a little less automated than its R counterpart.

Main conclusions from this article

  • IPython extension %autoreload and Marimo resolve module reloading issues

  • quartodoc can serve as {pkgdown}-like documentation tool

  • pre-commit And ruff replace devtools::check() for quality assessment

Comparison: R vs Python package development tools

Environment and dependency management{renv}uv, poetry, pip, venv
Package creationusethis::create_package()uv init --lib
Load/reload during developmentpkgload::load_all()%autoreloadMarimo
Documentationroxygen2, {pkgdown}docstrings, quartodoc
Unit testingtestthatpytest
Code quality and controlsdevtools::check()pre-commit, ruff
Website / documentation site{pkgdown}quartodoc + Quarter

The repositories are available here (with examples of notebooks).

Again, please feel free to point out any mistakes I may have made, or guide me through the things I had more difficulty with!

Thank you all, especially Joseph Barbier, James Azam, Uriah Finkel, Antoine Languillaume for providing feedback on the first article on this topic!


#Python #Package #Development #Developers #Episode #bloggers

Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *