maiste / eos Goto Github PK

Change Dockerfile and eos.opam to allow dependencies install with

 $ opam install . --deps-only

Add both command :

• show
• update [-vc]

Change the code to be functional and use the Result monad to manage error.

Write eos check, a command to check if a configuration is sane.

• Move from Travis to Github actions for testing.
• Change Docker Image to be lighter.

Write an eos init command that create a .eos directory if it didn't exists.

We decided to move from OUnit2 to mirage/alcotest because it's an active test framework with a better error displaying.

Needed for #52.

Make all documentation and description of phases.

Set up of Travis on the github repository.

Write a documentation in Sphinx about the user template.

Write a documentation in Sphinx about the header template.

• Merge into master
• Build a release

Etablishing of a test's module and a docker file for launch it.

As I'm working on the Eos documentation, I was wondering if we prefer to centralize the documentation along the project development docs or if we prefer to extract the documentation outside of the repo?

My first guess is to keep it here and well structure the mkdocs in several parts:

• header writer documentation
• user documentation
• dev documentation

What is your point of view on that @xavitator? Also, I've decided to move to mkdocs and not sphinx because I find it easier to maintain.

eos status [-d] must display files that needed to be updated. The flag d` displays the files current header.

• Add a description of the project
• Explain how to build from source:

  opam switch create . --deps-only

Etablish a writer system of files.

Considering that a header is added once and slightly modified with open source update, I was wondering if this project is not a complete waste of time ?

It was interesting to learn how to write a decent OCaml project together, but shouldn't this project be abandoned and archived….

Read a header template and adapt the user config file.