hercules-ci / flake-parts

❄️ Simplify Nix Flakes with the module system
https://flake.parts
MIT License
699 stars 38 forks source link

Flakestry releases #208

Open felschr opened 6 months ago

felschr commented 6 months ago

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 https://github.com/flakestry/flakestry.dev/pull/35. However it looks like it'll be merged soon.

shanesveller commented 6 months ago

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 commented 6 months ago

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.