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

Flakestry releases #208

Open
felschr opened this issue Jan 29, 2024 · 2 comments
Open

Flakestry releases #208

felschr opened this issue Jan 29, 2024 · 2 comments
Labels
enhancement New feature or request

Comments

@felschr
Copy link

felschr commented Jan 29, 2024

It would be really cool if flake-parts would be on Flakestry.

Here is the announcement post in the NixOS forum:
https://discourse.nixos.org/t/announcing-flakestry-dev-new-registry-for-flakes/34583

Publishing rolling releases is currently blocked by flakestry/flakestry.dev#35. However it looks like it'll be merged soon.

@shanesveller
Copy link

The DetSys FlakeHub site handled their own mirroring of desirable inputs without forcing the owners to add a CI step for their own benefit. Flakestry could follow a similar strategy if they want to help adoption of their tool, otherwise we'll see pleas like this one on most repos, which I don't think is necessarily a fair burden.

@roberth
Copy link
Member

roberth commented Jan 29, 2024

Do you have an concrete reason why you need this?
Nix works quite well without semantic versioning, and flake-parts in particular, which is very conservative with change. (or anything really) If something broke for you (did it?) that would be a bug to be fixed, and is very unlikely to require a major release.

So while I don't see much immediate benefit, I think at some point it may be useful. By maintaining both systems that flake-parts couples with: Nix and the module system, I can actually state with some confidence that this will take a long time before it's useful.

Finally I'd like to avoid GHA. Last time I checked, it seemed that auth was coupled to GHA specifically, so either

Hardcoding a forge in the registry URL layout seems like a bad idea, so I hope the latter will be implemented, even if less convenient.
I'd like to help out with these issues in flakestry, but it's not a priority right now.

semantic versioning

This could also be implemented for git: and github: flakerefs. Delegating this to registries seems rather heavy handed to me. Afaict there's currently no technical reason to prefer this, except that it just isn't implemented yet.

@roberth roberth added the enhancement New feature or request label Jan 29, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants