Skip to content

Conversation

@tomprince
Copy link
Contributor

This allows using the nix portion of morph, without needing to know implementation details of where the nix expression is.

I'm not sure if the attributes exposed there want to be made public, or perhaps only some of them should be public.

@srhb
Copy link
Contributor

srhb commented Nov 17, 2021

Can you explain the use case a little more? I think that it's a little weird compared to using the (import morph.lib [...] directly, which already seems pretty simple. :)

@tomprince
Copy link
Contributor Author

Can you explain the use case a little more? I think that it's a little weird compared to using the (import morph.lib [...] directly, which already seems pretty simple. :)

I took inspiration from arion (which has a similar function here). If/when this change is included into nixpkgs, one benefit is that using pkgs.morph.eval { inherit networkExpr; } instead of import "${pkgs.morph.lib}/eval-machines.nix" { inherit networkExpr; } is that the former will use the nixpkgs morph is pulled from, rather than whatever <nixpkgs> happens to point to.

Also, by having an explicit function be the interface for using morph from nix, rather than a file in the derivation, it isolates the user from how exactly morph is implemented and built.

@tomprince
Copy link
Contributor Author

I'll rebase this after #167 lands, since this re-indents default.nix.

@srhb srhb added the triaged Discussed in-team, actionable label Mar 4, 2022
@srhb
Copy link
Contributor

srhb commented Mar 4, 2022

I am happy with this, did you want to rebase? 😸

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

triaged Discussed in-team, actionable

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants