{"id":18002958,"url":"https://github.com/lucasdicioccio/deptrack-project","last_synced_at":"2025-03-26T08:31:21.971Z","repository":{"id":59152027,"uuid":"80344122","full_name":"lucasdicioccio/deptrack-project","owner":"lucasdicioccio","description":"monorepo for DepTrack","archived":false,"fork":false,"pushed_at":"2018-09-16T17:46:59.000Z","size":6372,"stargazers_count":40,"open_issues_count":1,"forks_count":5,"subscribers_count":7,"default_branch":"master","last_synced_at":"2025-03-21T12:22:12.358Z","etag":null,"topics":["dependency-graph","description-language","devops"],"latest_commit_sha":null,"homepage":null,"language":"Haskell","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":null,"status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/lucasdicioccio.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":null,"code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null}},"created_at":"2017-01-29T12:11:40.000Z","updated_at":"2024-03-21T16:49:35.000Z","dependencies_parsed_at":"2022-09-13T10:50:27.427Z","dependency_job_id":null,"html_url":"https://github.com/lucasdicioccio/deptrack-project","commit_stats":null,"previous_names":[],"tags_count":0,"template":false,"template_full_name":null,"repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/lucasdicioccio%2Fdeptrack-project","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/lucasdicioccio%2Fdeptrack-project/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/lucasdicioccio%2Fdeptrack-project/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/lucasdicioccio%2Fdeptrack-project/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/lucasdicioccio","download_url":"https://codeload.github.com/lucasdicioccio/deptrack-project/tar.gz/refs/heads/master","host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":245618763,"owners_count":20645064,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":["dependency-graph","description-language","devops"],"created_at":"2024-10-29T23:24:44.371Z","updated_at":"2025-03-26T08:31:20.492Z","avatar_url":"https://github.com/lucasdicioccio.png","language":"Haskell","funding_links":[],"categories":[],"sub_categories":[],"readme":"DepTrack project\n================\n\nUmbrella repository for the various DepTrack projects.\n\n# Goal of DepTrack.\n\nDepTrack is an approach more than a tool. The key finding of the DepTrack\napproach is that programs _logs are more useful when shaped like a tree_ than\nwhen shaped like a sequence. Using such an approach, rather than manually\nconnecting nodes in a graph, one can focus on computing a value which describes\na high-level goal and _records_ a tree of dependencies used during the\ncomputation.\n\n# Sub-projects\n\n## deptrack-core\n\nThe lowest-level brick, a monad transformer to describe trees and\ndirected-acyclic graphs. This brick allows you to write DSL-like libraries that\nrecord directed-acyclic graphs with a node type that best describe your\nproblem. This approach let you decouple how you _operate_ on (i.e., what you do\nwith) the graph from _express_ (i.e., which library builds) the graph. This\nway, the day you feel like DepTrack is no longer suitable to express your\ndependency graph you can still keep your functions to operate on the graph.\n\n## deptrack-devops\n\nThis library uses deptrack-core to perform Devops tasks.  Devops is a job\ntitle, and Devops engineers need to do two main things: (a) describe an\ninfrastructure and, (b) evaluate the description (e.g., to make the world\nconverge towards their intention, or to diagnose which bits of the system\ndiverged too much). In particular, (a) encodes a dependency graph between\nvarious subsystems of the infrastructure: faults and outages follow\ndependencies. Hence, the Devops space is a good playground for the DepTrack\napproach of building dependency graphs.\n\nThe author was dissatisfied with existing Devops tools: some existing tools\nclaim to use a declarative syntax (generally YAML) but actually use\ntemplated-YAML. As a result, the actual description of an infrastructure (a) is\na mix of a template language and a description language. The language used in\nthe evaluator (b) often is the same scripting language as the one used in the\ndescription, however they do not interact well: a main program provided by the\nsolution is in charge of generating the description and evaluating it. Such\nmain programs impose structure (which can be useful at times) but leave little\nroom for creativity.\nLast, the fact that scripting languages dominate the Devops tools space is\nannoying because applications written with scripting languages are ironically\nhard to deploy and have poor performance (and abismal multicore scalability).\n\nExisting tools have a number of drawbacks:\n- using YAML as a description language prevents taking advantage of libraries\n  (e.g., running a database query when generating the description, or verifying\n  some configs with a testing framework)\n- it's hard to manipulate the resulting graph by hand if the evaluation\n  language varies from the infrastructure description language or if the\n  evaluator is a monolithic program\n- the devop configuring description does not build an understanding of the\n  internals of the interpreter (I believe such opacity encourages copy/pasting\n  to work around problems)\n- the split between computation/declaration forces a code/configuration split\n  as well. Such split can become un-natural and imposes extra jargon because\n  the actual infrastructure description is the encouter of the computations\n  with the static/declarative parts.\n\nOur industry needs to empower Devops to describe infrastructure and operate on\nthe description creatively (e.g., generating statistics/simulations from such\ndescriptions). DepTrack is an attempt to move the state of the art forward.\nOnce you have a graph and manipulate it, you can estimate resource needs, you\ncan budget your monitoring on the most critical bits etc.\n\nThis library is written in Haskell and requires Devops to also describe\ninfrastructure in Haskell.  Using Haskell for DepTrack has the following\nadvantages:\n- Devops are in charge of the dependency graph evaluation. This repository\n  provides the basics way of building dependency graphs and let you write your\n  main program as you wish. This approach let you read, expose, and manipulate\n  configurations as your organization needs it rather than trying to retrofit a\n  Devops tool on your organization. It's not more work because it needs fewer\n  \"ugly hacks\".\n- One can modify the dependency graph before evaluating it (e.g., to batch\n  actions that can be done together)\n- The type system ensures that the graph generation is deterministic (i.e.,\n  a same input gives the same dependency graph)\n- The type system allows you to speak about high level concepts such as \"remote\n  services providing Foo\", \"local service consuming Foo\", and making sure you\n  bind these two things correctly together\n- Haskell usually compiles to an easy-to deploy binary.\n- Haskell comes with mature libraries, best-in-class testing frameworks, and\n  profiling tools. You can leverage all of this using DepTrack for DevOps.\n\nOne drawback of using Haskell is that there's more upfront learning than\nlearning YAML+scripting languages. However, longer term, the author believes\nyou can reach further with DepTrack than existing Devops tools.\n\n## deptrack-devops-recipes\n\nThis module provides some recipes to configure machines. It contains things I\nfound useful to configure my personal servers; mostly Debian-like.\nOrganization of this module is likely to change. See the README in this\ndirectory to have an up-to date description.\n\n# Using DepTrack Devops\n\nWe provide a Mustache template to start new DepTrack for Devops projects.\nAfter installing the Haskell Stack tool, you can do as follows:\n\n```shell\nstack new my-project https://raw.githubusercontent.com/lucasdicioccio/deptrack-project/master/deptrack-devops.hsfiles\n\ncd my-project\n\nstack build\n```\n\nYou can also study and modify the examples from deptrack-devops-examples.\n\n- clone the repo\n- stack install the repo\n- take example on deptrack-devops-examples/ to build your binaries\n\nThis can be done as follows\n```shell\ngit clone https://github.com/lucasdicioccio/deptrack-project.git\ncd deptrack-project\nstack setup\ncd deptrack-devops-examples\nstack install\n```\n\n# Contributing to DepTrack\n\nContributions to DepTrack projects are welcome. Please use GitHub issues for\ndiscussions. Please add yourself to the Contributors list in your pull\nrequests.\n\nThe bulleted-list of the DepTrack contributor is as follows:\n- be humble\n- be fair\n- be kind\n- be patient\n- all contributions matter (even one-char typos fixes in documentation)\n\n# Contributors \u0026 Thanks\n\nSorted by first name:\n\n- Arnaud Bailly (https://github.com/abailly)\n  - plenty of intellectually-challenging discussions\n  - base implementation for reference nodes that are resolved at turnup\n- Lucas DiCioccio (https://github.com/lucasdicioccio)\n  - inventor \u0026 maintainer\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Flucasdicioccio%2Fdeptrack-project","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Flucasdicioccio%2Fdeptrack-project","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Flucasdicioccio%2Fdeptrack-project/lists"}