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

src/data using non-overridable flake.lock holding nixpgks from the distant past #393

Open
nazarewk opened this issue Oct 16, 2024 · 3 comments

Comments

@nazarewk
Copy link
Contributor

nazarewk commented Oct 16, 2024

So I tried to reason about those warnings:

trace: warning: getExe: Package "conform-0.1.0-alpha.27" does not have the meta.mainProgram attribute. We'll assume that the main program has the same name for now, but this behavior is deprecated, because it leads to surprising errors when the assumption does not hold. If the package has a main program, please set `meta.mainProgram` in its definition to make this warning go away. Otherwise, if the package does not have a main program, or if you don't control its definition, use getExe' to specify the name to the program, such as lib.getExe' foo "bar".
trace: warning: getExe: Package "treefmt-0.5.0" does not have the meta.mainProgram attribute. We'll assume that the main program has the same name for now, but this behavior is deprecated, because it leads to surprising errors when the assumption does not hold. If the package has a main program, please set `meta.mainProgram` in its definition to make this warning go away. Otherwise, if the package does not have a main program, or if you don't control its definition, use getExe' to specify the name to the program, such as lib.getExe' foo "bar".

I did not have ANY reference to such nixpkgs definition in my flake code, then looking around lib.getExe usages only 2 candidates are inside

${lib.getExe nixpkgs.conform} enforce --commit-msg-file {1}'';

then I have noticed flake.nix and flake.lock lying around in src/data/ referencing nixpkgs commit holding the faulty treefmt-0.5.0

I have no idea how and why this happens, but seems like src/data is loading and using packages from nixpkgs dated at 2023-09 with no way to modify this behavior downstream.

@nazarewk
Copy link
Contributor Author

sounds like paisano is trying to load cell blocks as flakes in here, I don't think this is a good idea for the default/undocumented behavior.

@nazarewk
Copy link
Contributor Author

seems like I have triggered the issue myself with #374 unaware of how it works underneath

nazarewk added a commit to nazarewk/std that referenced this issue Oct 17, 2024
@blaggacao
Copy link
Collaborator

The reason really was to get "ahead" of stable nixpkgs for tooling that was just added, while maintaining the rest of standard on a release branch. Or more generally to decouple the lifecycles of some cell dependencies from the main flake dependencies.

Another aspect was to maintain a low dep.profile on the main flake.

But because cella depend on std it became self-referential in a lockstep update process that needed to be done manually.

This is because nix doesn't trust super references as inputs blanket, but locks them as anything else, which leads to a situation where the very act of locking within a repo of itself changes the lock hash of that repo.

nazarewk added a commit to nazarewk/std that referenced this issue Oct 25, 2024
nazarewk added a commit to nazarewk/std that referenced this issue Oct 25, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants