Project structure

[dierickxsimon]

I was thinking of the next few steps we need to take and tough maybe it's a good point to start thinking about the project structure. Below a concise overview of what have already been discussed.

general design

A composite design pattern with a general Fitfile class that act like a container and all the different messages as a component. (good way for new developers to see what information a fit file contains is https://www.fitfileviewer.com/)
A easy read_fit file which return the records of the fitfile as a pandas dataframe (or polars)? The rest of the package can then be used to play around with the rest of the raw data.

feature ideas

• Reading fit files
• Writing fit files from other file types
• Writing structured workouts
• Reading other file types (.zwo, .tcx, …)

Documentation

I think it’s a good idea to start the documentation as soon as possible even if it’s only for helping new contributors getting started (already very clear in de DEVELPOMENT.md file but do we need to transfer it to the mkdocs ...). Right now it seems like everyone was a fan for mkdocs with its material design. But it’s maybe worth starting a new issue for documentation only.

next steps

• Creating an overview of a file structure to follow in the DEVELOPMENT.md
• Any other next steps we need to think about before starting to create the Fitfile container ect?

[AartGoossens]

I like this overview. Some thoughts/comments/questions:

• I feel like we should just get started with defining the Fitfile class (defining the attributes etc.) in a WIP PR. The read_fit() can follow later from this. Do you want to take lead on that?
• User documentation should definitely be in mkdocs, but I think it would be actually OK to have developer/contributor docs in DEVELOPMENT.md (or CONTRIBUTING.md). I can create a structure for this.
• About pandas vs. polars: Although I like the performance benefits of Polars, I think we should start with returning a pandas dataframe: There are some differences (like the lack of indices) with polars that could make it harder for people to get started and I think that is what we should optimize for.

[AartGoossens]

One more comment I just thought of:

• How generic should this library be? I.e. will .fit files be the only file format this library support, or do we want to eventually provide a similar interface for .tcx and .parquet files and maybe even for REST API's? I think this could affect how we implement the composite pattern and the attributes on the Fitfile class (in the sense that we might ignore fields that are really specific to .fit).

[dierickxsimon]

Good comments, I think we should aim for a similar interface for all files types and even REST API's. But I also think we should try to keep all data in the fit files (or other data sources) accesible. Maybe in a MetaData object that has a somewhat different interface for all file types?

[AartGoossens]

Agree, it should be a unified interface regardless of the file format. I think there are ways to even make the metadata unified, but that we'll find out along the way.
Can you make a start with the Fitfile class and project structure? I think we should just get going with the code.

[dierickxsimon]

created a PR #7 with the first steps.