Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[RFC 184] versioned flakes references #184

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
55 changes: 55 additions & 0 deletions rfcs/0183-versioned-flakes.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,55 @@
---
feature: versioned-flakes
start-date: 2024-11-25
author: domenkozar
co-authors: None
shepherd-team: None
shepherd-leader: None
related-issues: None
---
## Summary

Introduce a standardized versioning schema for Nix flakes using [SemVer](https://semver.org/),
Copy link
Member

@inclyc inclyc Nov 25, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is a problem in semver:

how can we prove two packages are semantically same, even if their versions are different?.

It is more reliable if: any package update will trigger "full-rebuilds" for those dependent on it.

I just feel a little bit strange about introducing "SemVer" here.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm confused, isn't this RFC about versioning flakes, not packages?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm confused, isn't this RFC about versioning flakes, not packages?

That's the interesting paradox: if we don't use semantic versioning (SemVer) for packages, why should we use SemVer for flakes?

If there are valid reasons for using SemVer with 'flake' dependencies, why wouldn't those same reasons apply to packages as well?

Copy link
Member Author

@domenkozar domenkozar Nov 25, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How will you apply semver to nixpkgs flake?

following lessons learned from [RFC 144](https://github.com/NixOS/rfcs/pull/144/files).

Adds to flakes:

- `version` attribute to `inputs` in the top-level of `flake.nix` to specify version of the input to be resolved.
- An attribute `version` in the top-level of `flake.nix`.

## Motivation

Currently, Flakes lack a formal versioning mechanism, leading to potential duplication of dependencies and inefficient evaluations.

By adopting a versioning schema similar to Rust's Cargo system, we can utilize a SAT solver to manage dependencies more effectively, minimizing redundancy and improving performance.

## Explanation

- **Version Schema:** Implement a versioning system for flakes that follows SemVer conventions (e.g., `1.0.0`, `2.1.3`).
- **Input Versioning:** Allow flake inputs to specify version constraints (e.g., `inputs.nixpkgs.version = "^3.0.0";`) following [Rust Caret Requirement Syntax]([https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#version-requirement-syntax](https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html#caret-requirements)).
- **Dependency Resolution:** Integrate a SAT solver to resolve dependencies based on specified versions, ensuring compatibility and reducing duplication.

### Examples

**Defining a Flake with a Version:**

```nix
{
version = "1.0.0";
inputs = {
nixpkgs.url = "github:NixOS/nixpkgs";
nixpkgs.version = "^1.0.55";
};
outputs = { self, nixpkgs }: { /* ... */ };
}
```

### Implementation

Nix would resolve versions as part of the evaluation, shipping a SAT version resolver.

`flake-compat` wouldn't support version resolving.

[flakestry.dev](https://github.com/flakestry/flakestry.dev) would provide an HTTP API for resolving by preevaluating flakes.