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

RFC: File based config #27

Closed
coffee-cup opened this issue Apr 5, 2022 · 5 comments
Closed

RFC: File based config #27

coffee-cup opened this issue Apr 5, 2022 · 5 comments

Comments

@coffee-cup
Copy link
Contributor

coffee-cup commented Apr 5, 2022

Nixpacks configuration should be able to be provided through a file on disk in the app source. The main benefit is that build configuration can be tracked through source control.

At the moment, the configurable options are

  • Nixpkgs to install
  • Build command
  • Start command

A very basic format for these options is a JSON file

{
  "packages": ["pkgs.cowsay", "pkgs.lolcat"],
  "startCommand": "...",
  "buildCommand": "..."
}
@coffee-cup coffee-cup changed the title Read build options from repo RFC: File based config Apr 5, 2022
@aleksrutins
Copy link
Contributor

Would it be feasible to do this through a .nix file? In my opinion, the declarative configuration syntax is one of Nix's greatest strengths, and it would be great to integrate that with Nixpacks. I don't know how it would be implemented, and I don't know that much about Nix, but I was thinking about something along these lines in terms of syntax:

{stdenv, nixpacks}: rec {
  derivation = stdenv.mkDerivation {
    # ...
  };
  deploy = nixpacks.configure {
    inherit derivation;
    startCommand = "./whatever";
    # Since the package is already built by the derivation, you shouldn't need a separate build command here
  };
}

Or something like that.

@coffee-cup
Copy link
Contributor Author

That could work. And I do think it is a good idea to be able to import/build Nix projects with zero-config. However, I am not sure this is the right approach for all projects. Ideally, users can use all features of Nixpacks without having to know and understand the Nix expression language (see core ideas in readme). This is also something you have to opt into completely and means that if you want to save the start command to version control you will have to also figure out how to build your app with Nix and cannot take advantage of the providers.

That being said, looking for and building a default.nix or a flake.nix is a great idea. We could have a NixProvider that does this.

@aleksrutins
Copy link
Contributor

aleksrutins commented Apr 6, 2022

An idea: if Nixpacks were to export some sort of interface to Nix expressions, then would it be possible to also export the providers? Maybe even provide some sort of wrapper around mkDerivation, to allow the user to have the best of both worlds (zero-config Nix expressions)? Something like this, maybe:

{nixpacks, stdenv, myDependency}:
nixpacks.mkDerivation {
  # All options are optional; `extends` would default to stdenv, most likely.
  extends = stdenv;
  buildCommand = "whatever";
  runCommand = "./whatever";
  packages = [ myDependency ];
}

That might take whatever the extends option is and then wrap extends.mkDerivation with the required build steps and dependencies.

@coffee-cup
Copy link
Contributor Author

Oh yeah that is a neat idea. It would allow us to leverage the Nix ecosystem a bit more too. I'll play around with it.

@ghost
Copy link

ghost commented May 14, 2022

Moved to discussions (#120)

@ghost ghost closed this as completed May 14, 2022
This issue was closed.
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