Environments don't seem to be registered as devShells

[DeviousStoat]

Here is my flake (mostly generated with nix run 'github:tek/hix?ref=0.8.0#new' -- --name 'test-envs' --author 'Me'):

{
  description = "A Haskell project";
  inputs.hix.url = "github:tek/hix?ref=0.8.0";
  outputs =
    { hix, ... }:
    hix (
      { config, ... }:
      {
        hackage.versionFile = "ops/version.nix";
        cabal = {
          license = "BSD-2-Clause-Patent";
          license-file = "LICENSE";
          author = "Me";
          ghc-options = [ "-Wall" ];
        };
        envs.example = {
          ghc.compiler = "ghc94";
          buildInputs = [ config.pkgs.socat ];
          services.postgres = {
            enable = true;
            config = {
              name = "test-db";
            };
          };
        };
        packages.test-envs = {
          src = ./.;
          cabal.meta.synopsis = "A Haskell project";
          library = {
            enable = true;
            dependencies = [
              "containers"
            ];
          };
          executable.enable = true;
        };
      }
    );
}

If I try to enter the dev shell:

❯ nix develop .#example
error: flake 'git+file://(...)/test-envs' does not provide attribute 'devShells.x86_64-linux.example', 'packages.x86_64-linux.example', 'legacyPackages.x86_64-linux.example' or 'example'

Am I doing something wrong?

I also tried running the included postgres service from the dev env instead but seems it doesn't start when entering the dev shell.

[DeviousStoat]

I also tried running the included postgres service from the dev env instead but seems it doesn't start when entering the dev shell.

About this, I realized that the services don't run in direnv initialized dev shell. When I run it manually it works well, nevermind, probably a good thing.

[tek]

envs are only added to devShells if envs.example.expose.shell = true; is set. I forgot to add that to the manual before the last release, sorry! I added it since, but haven't deployed it yet.

[tek]

I added the option to the example as well. Thanks for the report! Maybe this should be reverted to expose unless disabled...

[DeviousStoat]

ooh yeah! awesome! thank you very much!

sorry!

This is an really cool project, I am having a lot of fun using it and the documentation is very detailed, you are so excused

[tek]

I'm very happy to hear that ☺

[DeviousStoat]

since you seem very responsive, I take this opportunity to ask. Would really like to help on this, I am really enjoying everything you are doing with this. Would you be interested in me trying to add a way for the new command to create the directory along with the current behaviour of initializing the current directory? maybe as an additional option or separate init for current and new for create directory? Found myself missing that, and even got a bit confused at first, thought new would create because of the name but maybe that's just me

[tek]

sure, I'd be glad to accept contributions!

your reasoning sounds sensible, though backward compat is probably more crucial for this command than others...how about adding an optional positional argument for the directory? If it's omitted, we fall back to the current dir; if given, it also sets the --name?

I'd assume that most people would either copy the command from the readme or run --help first, so the confusion could be eliminated by being explicit about this.