Windows LF vs CRLF line endings

[Zeddicus414]

Hey all,

I ended up in a sort of line ending hell caused by my git config along with marimo's autosave.

The behavior that I'm seeing: Running marimo in windows will always convert the notebook.py file to CRLF line endings, no matter what I configure.

What I want: Marimo uses linux line endings or leaves the line endings alone rather than converting them to CRLF.

Things I've tried:

• Putting the tool.ruff.format.line-ending = "lf" in the pyproject.toml
• Using ty as the language server (I hoped that it might honor the ruff config better)
• Looking at the Marimo docs trying to find something that might help
• Messing around with the git "autocrlf" settings, although, I don't think there is a good solution here.

Can anyone please help? I have searched the issues and discussions for similar problems and I haven't found any mention of it.

[dmadisetti]

What's your gitconfig lineconfig? core.autocrlf false ? I think we can try to respect this. I think we use ruff when serializing if it's available. I'm not sure why it would be ignoring your settings.

[Zeddicus414]

I have core.autocrlf unset, which I believe is the same as "False". By convention, we have all of our .py files as linux line endings, and we have it configured as text in our .gitattributes file. To be honest, it's been a while since I've gone through all of git's line ending options, so I'm a bit fuzzy on exactly why we ended up with the settings that we have. But I know the primary goal was to have as much of the line ending configuration in our codebase so that messing up git client settings wasn't a huge problem.

I am running the marimo like so: uv run --with marimo[recommended] --watch my_notebook.py. So marimo is being run in a python project that has ruff as a dependency in the pyproject.toml and in the uv.lock, but marimo isn't really a dependency. It's just being added by uv at runtime. I'm not sure if that somehow ends up with two different ruff binaries or not... maybe that's why ruff isn't honoring the configuration in the pyproject.toml?

I did find a solution that works, which is naming my file my_notebook.mo.py and putting *.mo.py binary in the .gitattributes, which tells git to just leave the file alone no matter what. It is then committed with CRLF line endings. Although, this isn't the best long term solution since it's treated different than our other python files, and will probably raise the "line endings dragon" again at some point!

I would like to say thank you for working on marimo! It's super cool and having the watch feature along with the data exploration while coding has been lovely! It's seems to have solved the "jupyter notebooks are black boxes that only the author can ever get to work again" problem in a really wonderful way!

Thanks for the help!