Project approval discussion: Installation improvements

[Kriti Godey]

Hey everyone,

Please review the project Installation improvements and respond here if you have any concerns or questions.

General things to think about:

• Do the project’s goals, solutions, and timelines make sense?
• Does the team make sense, does anyone else need to be involved?

If no concerns are raised by end of day Monday (Jul 17), we’ll consider the project approved.

Kriti

[Kriti Godey]

Mukesh, I see the project wiki page says it’s a WIP. Is this ready for review?

Some general feedback:

• Please follow the project template, the current page is difficult to parse.
• The problem and solution outlined in the page is difficult to understand (read through the page and imagine you’re reading this as someone who’s not that familiar with Mathesar’s installation). I would recommend structuring it more like your notes in HackMD, or publishing those notes separately and referencing them. The sections “Current steps involved with Installing Mathesar” and “Solutions to reduce the steps involved with installing Mathesar” are especially useful to understand what you’re proposing in this project, but none of that information is in the project page.
• I am not sure if the work you’re proposing involves building static files on release or not. Can you clarify that?
• I recommend renaming the project to “2023-07 installation improvements” or “0.1.3 installation improvements”, as there may be more installation improvements projects in the future.

[Kriti Godey]

One more thing: at the last installation meeting, we decided that part of this project would involve continuing discussions about what installation personas we're targeting. This is not reflected in the project wiki page – it should be specified in both the goals section and the outcome section.

[Dominykas Mostauskis]

I'm surprised that adding SQLite support is in this project. That seems like a big undertaking (though I've not given it serious thought). What's more, that's only one of the tasks involved. Is the scope of this project not too large?

[Sean Colsen]

Dom,

My understanding from having been in the installation planning meetings is that the plan is to add SQLite support only for the internal database (i.e. the Mathesar database which holds metadata, as used by Django). Mukesh says that’ll be pretty simple since Django already has support for SQLite. The project page could probably do a better job at making that clear to readers like you.

​

[Dominykas Mostauskis]

Thanks for the clarification.

[Mukesh Murali]

Sorry, the Project page hasn't been updated yet. I made a lot of changes to it but couldn't push it due to technical issues. Please hold off until I update it and mark it as for review.

[Mukesh Murali]

I updated the project page. Can you review it now.

[Kriti Godey]

Mukesh and I did some work on this project in a call. The new URL is https://wiki.mathesar.org/en/projects/installation-improvements-0_1_3.md.

I’m going to extend the deadline for reviewing this project to the end of day tomorrow (Tue, Jul 18) since it’s been a WIP for so long. Please let me know if anyone needs more time.

Mukesh, as discussed, the timeline section still needs some changes:

• Please verify with project helpers individually that the timeline works for other people working on the project (e.g. Ghislaine working on design work) and that the expectations for them are clear.
• Consider splitting up the timeline into weekly deliverables rather than having precise dates, unless you and everyone else helping is willing to commit to precise dates.
• Also consider splitting the timeline into multiple tables (one for discussion, one or more for implementation) for readability.

Please also add GitHub issues and make sure to incorporate the user reported issues already listed on the page into whatever meta-issue you create.

Otherwise, the project looks good from my end.

Please update this thread once the timeline and issues are updated. Thanks!

[Pavish Kumar Ramani Gopal]

I took a quick look at the plan and I doubt it'd be feasible for me to start work on the UI for it during this cycle.

As discussed during the weekly meeting, @Rajat Vijay would you like to take over implementation and I could take over review?

[Kriti Godey]

I forgot to add: Mukesh, please add some time for us (you and me) to plan out the installation related meetings to decide on what the meeting topics should be.

[Mukesh Murali]

Thanks for the review @Pavish Kumar Ramani Gopal and @Kriti Godey 

• Please verify with project helpers individually that the timeline works for other people working on the project (e.g. Ghislaine working on design work) and that the expectations for them are clear.
  

• - Ghislaine confirmed it on a dm over Matrix
  - Since Pavish is unavailable, I replaced him with Rajat as the frontend helper. 
  - I have sent a message to @Rajat Vijay . Yet to get a confirmation from him.

• Consider splitting up the timeline into weekly deliverables rather than having precise dates, unless you and everyone else helping is willing to commit to precise dates.
  

• Done

• Also consider splitting the timeline into multiple tables (one for discussion, one or more for implementation) for readability.
  

• I removed the timeline for discussion as it is susceptible to change and replaced it with a tentative meeting plan which includes the topics we might discuss every week and allocated some time for us to meet before scheduling a meeting which includes other team members.

[Kriti Godey]

Thanks Mukesh, this looks good to me. I fixed some minor typos (commit 1, commit 2).

If there are no other concerns raised by the end of day, and once Rajat confirms he can commit to the work, we can mark this as approved.

[Mukesh Murali]

@Ghislaine Guerin and @Rajat Vijay I updated the timeline to include a date for design and frontend work. I gave a buffer of additional 2 days to the dates we agreed on Matrix.

[Pavish Kumar Ramani Gopal]

I'm sorry for not noticing these earlier, I have a few questions.

1. What does 'Build from source' mean?

• I remember we discussed we will not actually be building from source.
• In the project page, it mentions the installation step would be 'apt install' for debian, and installing python and zipapp for non-debian, so I assume it is not really "building from source", but instead installing a package.
• Could we change the name for this installation method to make it more clear?

2. Installation methods that need SQLite need to be documented more.

• The project page and the overview diagram do not give enough information on which installation methods will require SQLite.
• For the default Mathesar image, would SQLite always be included?
• Wouldn't this be a bloat for PaaS (and any production server) installation methods, since it's recommended to keep a single DB running separately for it?

3. How will the installation steps page look like for the end-user?

• I'm concerned if we go about this from a bottom-up approach, where we create all installation methods, and then write up documentation, we'll end up with a mess similar to what we have with our current setup.
• I think it might make a lot of sense to have a rough draft of how the installation documentation will look like from a user perspective first, which might help us make critical decisions with setting up the installation methods. 

[Rajat Vijay]

Thanks, Mukesh. These timelines and work details looks good to me.

[Mukesh Murali]

What does ‘Build from source’ mean?

Thanks for the catch, it should be called “Non-Docker” Install.

Installation methods that need SQLite need to be documented more.

The stretch goals were meant to be for laying the groundwork for the next cycle and not meant to be self-contained. So for “adding SQLite as an option data source for our internal database”, the idea was to just make changes to the codebase only. We will be adding documentation to it later. It applies to other solutions in the stretch goals too. I will update the project to make it clear that we are only laying the groundwork for future projects.

Wouldn’t this be a bloat for PaaS (and any production server) installation methods, since it’s recommended to keep a single DB running separately for it?

As I mentioned on our Matrix chat, an SQLite DB file will be created only if a Postgres connection is not provided.

How will the installation steps page look like for the end-user?

We discussed what the ideal flow would look like at our first meeting. But we haven’t considered it from a documentation perspective. I think it is a good idea to consider documentation too. I added an issue to the project to figure out that part.

Also, the outcomes of this project will help us answer this question better. So far we have been brainstorming potential solutions and picked up low-hanging fruits to fix which should not affect the installation process much. We will be forming a concrete plan at the end up of this cycle which should address these concerns.

I’m concerned if we go about this from a bottom-up approach, where we create all installation methods, and then write up documentation, we’ll end up with a mess similar to what we have with our current setup.

The current documentation is a mess because we never looked at our installation process from an end-user standpoint nor considered the user personas we should be targetting. A certain user who prefers to configure will need more details than someone who wants to try out Mathesar quickly and it is hard to write documentation without considering who we are writing it for. Also, the whole installation process is very primitive which makes documenting it harder. It is a chicken and egg problem and I don’t we could solve this in one go.

[Pavish Kumar Ramani Gopal]

Thanks Mukesh.

I don't have any further comments. I think it looks great!

[Kriti Godey]

Okay, marked the project as "approved".