├── .dependencies ├── CHANGELOG.md ├── CODE_OF_CONDUCT.md ├── LICENSE └── README.md /.dependencies: -------------------------------------------------------------------------------- 1 | # This file documents environment dependencies 2 | 3 | ruby: "~> 2.3", file: "Gemfile" 4 | postgres: "~> 9.3" 5 | python: "~> 2.7", file: "requirements.txt" 6 | node: "~> 5.5", file: "package.json" 7 | -------------------------------------------------------------------------------- /CHANGELOG.md: -------------------------------------------------------------------------------- 1 | # Changelog 2 | 3 | All notable changes to this project will be documented in this file. 4 | This project adheres to [Semantic Versioning](http://semver.org/). 5 | 6 | ## [0.1.0] - 2016-02-25 7 | ### Added 8 | - First draft of the "universal" .dependencies file 9 | -------------------------------------------------------------------------------- /CODE_OF_CONDUCT.md: -------------------------------------------------------------------------------- 1 | # Contributor Covenant Code of Conduct 2 | 3 | ## Our Pledge 4 | 5 | In the interest of fostering an open and welcoming environment, we as 6 | contributors and maintainers pledge to making participation in our project and 7 | our community a harassment-free experience for everyone, regardless of age, body 8 | size, disability, ethnicity, gender identity and expression, level of experience, 9 | nationality, personal appearance, race, religion, or sexual identity and 10 | orientation. 11 | 12 | ## Our Standards 13 | 14 | Examples of behavior that contributes to creating a positive environment 15 | include: 16 | 17 | * Using welcoming and inclusive language 18 | * Being respectful of differing viewpoints and experiences 19 | * Gracefully accepting constructive criticism 20 | * Focusing on what is best for the community 21 | * Showing empathy towards other community members 22 | 23 | Examples of unacceptable behavior by participants include: 24 | 25 | * The use of sexualized language or imagery and unwelcome sexual attention or 26 | advances 27 | * Trolling, insulting/derogatory comments, and personal or political attacks 28 | * Public or private harassment 29 | * Publishing others' private information, such as a physical or electronic 30 | address, without explicit permission 31 | * Other conduct which could reasonably be considered inappropriate in a 32 | professional setting 33 | 34 | ## Our Responsibilities 35 | 36 | Project maintainers are responsible for clarifying the standards of acceptable 37 | behavior and are expected to take appropriate and fair corrective action in 38 | response to any instances of unacceptable behavior. 39 | 40 | Project maintainers have the right and responsibility to remove, edit, or 41 | reject comments, commits, code, wiki edits, issues, and other contributions 42 | that are not aligned to this Code of Conduct, or to ban temporarily or 43 | permanently any contributor for other behaviors that they deem inappropriate, 44 | threatening, offensive, or harmful. 45 | 46 | ## Scope 47 | 48 | This Code of Conduct applies both within project spaces and in public spaces 49 | when an individual is representing the project or its community. Examples of 50 | representing a project or community include using an official project e-mail 51 | address, posting via an official social media account, or acting as an appointed 52 | representative at an online or offline event. Representation of a project may be 53 | further defined and clarified by project maintainers. 54 | 55 | ## Enforcement 56 | 57 | Instances of abusive, harassing, or otherwise unacceptable behavior may be 58 | reported by contacting the project team at hi@olivierlacan.com. All 59 | complaints will be reviewed and investigated and will result in a response that 60 | is deemed necessary and appropriate to the circumstances. The project team is 61 | obligated to maintain confidentiality with regard to the reporter of an incident. 62 | Further details of specific enforcement policies may be posted separately. 63 | 64 | Project maintainers who do not follow or enforce the Code of Conduct in good 65 | faith may face temporary or permanent repercussions as determined by other 66 | members of the project's leadership. 67 | 68 | ## Attribution 69 | 70 | This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4, 71 | available at [http://contributor-covenant.org/version/1/4][version] 72 | 73 | [homepage]: http://contributor-covenant.org 74 | [version]: http://contributor-covenant.org/version/1/4/ 75 | -------------------------------------------------------------------------------- /LICENSE: -------------------------------------------------------------------------------- 1 | The MIT License (MIT) 2 | 3 | Copyright (c) 2016 dependent 4 | 5 | Permission is hereby granted, free of charge, to any person obtaining a copy 6 | of this software and associated documentation files (the "Software"), to deal 7 | in the Software without restriction, including without limitation the rights 8 | to use, copy, modify, merge, publish, distribute, sublicense, and/or sell 9 | copies of the Software, and to permit persons to whom the Software is 10 | furnished to do so, subject to the following conditions: 11 | 12 | The above copyright notice and this permission notice shall be included in all 13 | copies or substantial portions of the Software. 14 | 15 | THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR 16 | IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, 17 | FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE 18 | AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER 19 | LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, 20 | OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE 21 | SOFTWARE. 22 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # .dependencies 2 | A file to define environment dependencies for applications 3 | 4 | ## Purpose 5 | Different programming communities have ways to document dependencies 6 | required for a program or application to function. 7 | 8 | Ruby has the [`Gemfile`](http://bundler.io/gemfile.html), 9 | Python has [`requirements.txt`](https://pip.readthedocs.org/en/1.1/requirements.html), 10 | and Node has [`package.json`](https://docs.npmjs.com/files/package.json). 11 | 12 | The `.dependencies` file expands on those good ideas in order to provide 13 | system-level dependency documentation. 14 | 15 | ## Example 16 | 17 | In a file named `.dependencies` at the root of your project: 18 | 19 | ```ruby 20 | ruby: "~> 2.3.0", file: "Gemfile" 21 | postgres: "~> 9.3.0" 22 | python: "~> 2.7.0", file: "requirements.txt" 23 | node: "~> 5.5.0", file: "package.json" 24 | ``` 25 | 26 | Let's break it down, by focusing on first line: 27 | 28 | 1. `ruby` is the name of the system-level software being dependend on by your program 29 | 2. `"~> 2.3.0"` defines the version constraint for the `ruby` dependency, `~>` means "loose" which is equivalent to saying "I want any version including 2.3.0 and above but below 2.4". 30 | 3. `file` is an optional key that allows you to specify where the system-level dependency can find its own dependencies, and in Ruby programs usually document their dependencies using a Bundler `Gemfile`. 31 | 32 | ## Why document dependencies in a file? 33 | 34 | The issue is that there are system-level dependencies that are often omitted 35 | from these dependency documentation systems. For instance it's rare for my Ruby 36 | applications to specify that they require PostgreSQL, Redis and ffmpeg in 37 | order to function. 38 | 39 | There are OS-specific solutions like the 40 | [Brewfile](https://robots.thoughtbot.com/brewfile-a-gemfile-but-for-homebrew) 41 | but they're only partially solving the problem because not everyone uses the 42 | same operating system (OS X in this case), and it's equally important to specify 43 | which version of the software you depend on. 44 | 45 | ## Benefits of `.dependencies` 46 | 47 | ### Obvious 48 | The file name makes its purpose obvious. It starts with a `.` and will 49 | show up early in the file tree because the letter "d" is early in the 50 | alphabet. 51 | 52 | ### Clarity 53 | Now let's talk about the contents of the `.dependencies` file. 54 | 55 | Eventually this file will be read by machine more often than by humans 56 | but considering how crucial it is to developers, it needs to be as 57 | human-friendly as possible. 58 | 59 | Parsing the file needs to be easy for both humans and machines. This is why 60 | it uses a simple key/value format. It does *look* like YAML, but it doesn't need 61 | to be. Not every machine out there can parse YAML. 62 | 63 | ```ruby 64 | postgresql: "~> 9.3.0" 65 | ``` 66 | 67 | ### Versions 68 | Why a quoted string for the version? Well, because Bundler's format is the best 69 | version specification format I know of. The string allows for complex 70 | modifications on the version number. It allows strict versions specifications 71 | (`"9.1.3"`), open-ended (`"> 0.1.0"`), ranges (`[">= 4.1.0", "< 5.1"]`), and even 72 | loose ones (`"~> 9.3.0"` meaning equal or greater than 9.3.0 but less than 9.4). 73 | 74 | ### Integrations 75 | Finally there's a little bonus, a second value called `file` which hints at 76 | where each system-level dependency should look for its own dependencies. This 77 | feels important to me because I don't intend this dependency specification file 78 | to replace all existing language-specific ones. I think there's a gap in our 79 | dependency documentations and I just want to fill it, not revolutionize 80 | everything. 81 | --------------------------------------------------------------------------------