I found a way to simplify non-docker Installations!

12 views
Skip to first unread message

Pavish Kumar Ramani Gopal

unread,
Jan 24, 2025, 8:26:52 PMJan 24
to Mathesar Developers
Hey team,

I came across uv a while back, and it's awesome!

I managed to bundle it and create distributions for linux_x64(amd), Apple macOS intel, and Apple macOS Silicon.

These distributions are NOT reliant on docker.

Here's what we get:
  • Users do not need to have python installed in the first place!!!
    • No more annoying problems with asking the users to install python.
    • python gets installed locally (not-globally) within Mathesar's installation folder.
  • Frontend is pre-compiled and is part of the distributions.
    • No need to host frontend assets anymore.
  • Django translations are pre-compiled and are part of the distributions.
However,
  • Users still need to have PostgreSQL running somewhere.
  • We don't bundle PostgreSQL and aren't going to be able to do so for a while.
    • It's not going to be easy, but technically possible for Windows and MacOS.

Here's the branch where I have the distributions and the build script: simplify-install.

Here's how you can install Mathesar and test. These commands are for Linux amd x64 platform (Use links further below if you want to install on Mac):

1. Have PostgreSQL running somewhere. Create a mathesar_django database in it.

2. Create a folder to install Mathesar, and cd into it.
    mkdir -p /etc/mathesar-test/
cd /etc/mathesar-test/

2. Download the linux_64 binary. Note: This distribution is amd based and will not work on ARM machines.

3. Extract it:
    tar -xzf mathesar-linux_x64.tar.gz

4. Set env variables and Run it:
    export SECRET_KEY='2gr6ud88x=(p855_5nbj_+7^bw-iz&n7ldqv%94mjaecl+b985'
export POSTGRES_DB=mathesar_django
export POSTGRES_USER=mathesar
export POSTGRES_PASSWORD=mathesar
export POSTGRES_HOST=localhost
export POSTGRES_PORT=5432

./run-uv.sh
   

That's it! Visit `localhost:8000` and Mathesar should be running.

If you face any error while running `run-uv.sh`, ensure you have gcc installed. This is needed for installing some of our python requirements like clevercsv.

Here are the download links for:

This heavily simplifies our install from scratch setups.
  • Makes Mathesar way more portable, enabling local-first installations.
  • We can build for more platforms if we want to. Eg., Linux arm platforms.
  • Opens the possibility of creating more sophisticated binary installation setups.
    • Imagine a 'Mathesar.app', or 'Mathesar.exe'.

Further steps/discussions I'd like to have:
  • I think we should consider creating distributions for our next release (after 0.2.0).
    • We already have a working POC.
  • We should restart discussions on considering SQLite for the Django database again.
    • I still think we should definitely allow creating databases from within Mathesar. We would have to find a different flow for it. 

I'm excited about this!

- Pavish.

Sean Colsen

unread,
Jan 25, 2025, 6:49:54 AMJan 25
to Pavish Kumar Ramani Gopal, Mathesar Developers
Wow, neat! I've only skimmed this, but I'm excited to dig deeper and respond with more thoughts!

Brent Moran

unread,
Jan 27, 2025, 3:20:32 AMJan 27
to Mathesar Developers
If this works, I'm super excited about that.

Regarding databases:
  • I agree we should discuss what to do about the Django database.
  • If we could choose not to support one of the following, installation would be improved and much simpler, regardless of  uv:
    • using the same database for both Django, and user data, or
    • connecting to external databases (i.e., databases different from the database used by Django).
Supporting both of those cases causes basically all of the headaches in our installation process (well, that and using the Python/Django stack).

I prefer the option where we no longer allow creating user databases on the Django DB. This means Mathesar would feel "more self-contained" to some users (if we changed to SQLite3 for the internal DB), if their expectation was to install Mathesar as essentially a client to some preexisting database. But, this will make Mathesar feel "less self-contained" for any user that understands the whole Mathesar stack, including the underlying databases, as one big product.

Pavish Kumar Ramani Gopal

unread,
Jan 27, 2025, 6:53:20 AMJan 27
to Brent Moran, Mathesar Developers
> Supporting both of those cases causes basically all of the headaches in our installation process (well, that and using the Python/Django stack).

I do think we can find some middle-ground.

Our problem occurs because we use a single PostgreSQL server for both the Django DB and the "internal" db where we create user databases.

We could try separating the concepts by,
1. Always using SQLite for our Django database.
2. Allowing the user to configure a "primary" PostgreSQL database connection for which Mathesar at least has CREATEDB privileges on (via env variables and/or the UI).

This way we could ship a "self-contained" Mathesar, and also allow installation methods such as docker-compose to ship Postgres pre-configured to be used as the primary db. UX-wise it'd work quite similar to how it works now. However,
  • The Django DB would be on SQLite.
  • The PostgreSQL DB would only be configured as "primary" for the sake of Mathesar to use it to create new DBs.
  • The user could configure any DB connection credentials as primary, and Mathesar would use it for creating new DBs by default.
  • We wouldn't have to worry about upgrading PostgreSQL and maintaining it.
This is of-course one idea that requires minimal work. We could workshop more solutions to allow both workflows.

I strongly think allowing creation of databases from within Mathesar is an important feature, while also supporting the idea to use SQLite for the Django DB.

Kriti Godey

unread,
Jan 27, 2025, 9:02:50 AMJan 27
to Pavish Kumar Ramani Gopal, Brent Moran, Mathesar Developers
This is all pretty awesome, Pavish. Please track it in GitHub too, when you have time.
Reply all
Reply to author
Forward
0 new messages