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

Value does not conform to 'function' when using with latest main std #12

Open
truelecter opened this issue Jun 25, 2023 · 4 comments
Open

Comments

@truelecter
Copy link
Contributor

After upgrading std to the recent version from the main branch, I've got an error

error: [/nix/store/6lw3c9jmg483mac19cfmdal9bfxsl2lq-source/flake.nix - grow[On]:cellBlocks]: expected type list<Cell Block>, but found:
       {
         actions = <function, args: {currentSystem, fragment, fragmentRelPath, inputs, target}>;
         name = "config";
         type = "nixago";
       }: expected 'Cell Block'-struct, but found:
       field 'actions': expected type option<function>, but value does not conform to 'function': expected <function, args: {currentSystem, fragment, fragmentRelPath, target}>, but arguments and/or defaults do not conform: <function, args: {currentSystem, fragment, fragmentRelPath, inputs, target}>

       {
         actions = <function, args: {currentSystem, fragment, fragmentRelPath, inputs, target}>;
         name = "shells";
         type = "devshells";
       } with __functor = <function>: expected 'Cell Block'-struct, but found:
       field 'actions': expected type option<function>, but value does not conform to 'function': expected <function, args: {currentSystem, fragment, fragmentRelPath, target}>, but arguments and/or defaults do not conform: <function, args: {currentSystem, fragment, fragmentRelPath, inputs, target}>

       {
         actions = <function, args: {currentSystem, fragment, fragmentRelPath, inputs, target}>;
         name = "packages";
         type = "installables";
       } with __functor = <function>: expected 'Cell Block'-struct, but found:
       field 'actions': expected type option<function>, but value does not conform to 'function': expected <function, args: {currentSystem, fragment, fragmentRelPath, target}>, but arguments and/or defaults do not conform: <function, args: {currentSystem, fragment, fragmentRelPath, inputs, target}>

It looks like new actions from std signature (after introducing inputs to the action function) are incompatible with what paisano expects (as hive's growOn is basically paisaon's one). As such, using both std's and hive's blocktypes is impossible when using hive.growOn

Changing it to std.growOn is not compatible with the current darwinConfigurations actions block as they lack inputs argument. This may be fixed with #11

@yousiki
Copy link

yousiki commented Jul 21, 2023

I just got the same error and found that using the latest version of paisaon seems fine. For example:

inputs = {
    paisano.url = "github:paisano-nix/core";
    paisano.inputs.nixpkgs.follows = "nixpkgs";

    hive.url = "github:divnix/hive";
    hive.inputs.nixpkgs.follows = "nixpkgs";
    hive.inputs.paisano.follows = "paisano";
};

I think the locked version of paisano is too old and it should be updated.
(BTW, github:divnix/paisano should be github:paisano-nix/core for now)

@blaggacao
Copy link
Collaborator

blaggacao commented Jul 21, 2023

I think I missed this issue report (or it was superseded by other priorities). Sry!

Let me have a look today, that should be a quick fix.

I wanted to work on release targets, but I realize std 0.30.0 will still take some time.

@Lord-Valen
Copy link
Contributor

This is because the std and hive revisions in use have different Cell Block structs, likely because they have incompatible versions of paisano. This is not the case on the latest commits of each project. Really, we just need to be careful to use compatible versions of std/hive. It'd be better if we didn't have to think so hard, though 😉.

@blaggacao
Copy link
Collaborator

Really, we just need to be careful to use compatible versions of std/hive.

& Paisano.

I thought about aligning all around a same version (e.g. 0.5.0) in the near future.

Pro:

  • Explaining compatibility becomes trivial
  • Changelog & Migration (where necessary) is easy to grok

Con:

  • If projects don't have largely speaking similar life cycles, it starts blocking each other
  • Because of that, all projects would need to stabilize a bit (which I think they have +-)

As for std, I still want to release better kubectl & terra block types + some golden template before bumping.

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

4 participants