How do you feel about having one for a Python/Nix project, one for Haskell/Nix project, one for a Node/Nix project etc as well?
I think we could create a separate cli utility like nix-template which would act like:
nix-template FRAMEWORK NAME. Where FRAMEWORK could be {python,haskell,node,go,rust,stdenv,qt,gtk,...} so an example would be:
nix-template python pkgs/development/python-modules/some-mod/default.nix
I’m still thinking how to best tackle languages.
There’s a lot we can do short term.
But long term we should probably come up with more conventions between them so it’s easier to switch from one to another.
I like the nix-template command or maybe nix project? Maybe it is too early for languages. On the other hand it would give a real reason and pressure for standardization to have all language frameworks in one tool.
I love that idea. I have my own personal language dependent templates which I call start-points.
@domenkozar is right in highlighting that long term should be thought up.
In this direction, I only want to stress that there are many possible variations, even by language or framework.
For c++, you could go for a Makefile build, or CMake… or Scons, or Bazel. You could go for gcc or for clang. Then you suggest qt or gtk… But you may also be a terminal app with ncurse, a service, or just an executable.
For haskell it could be to go for stack, or to go for cabal. But even if one way is chosen, there are further many declinations, for example look at Gabriel Gonzalez GitHub - Gabriella439/haskell-nix: Nix and Haskell in production.
=> There are several levels of complexity, which may or may not be needed by the user. And the more we add complexity, the less it may become beginner friendly.
How about going via framework rather than language. For example:
nix-template python myproject <-- default (e.g. uses nixpkgs python)
nix-template python -t poetry2nix myproject <-- uses poetry2nix
I’ve found that lockfile package managers integrate more easily with nix
Github has a nice template button feature now.
I think that’s worthwhile to look into or even GitHub - cookiecutter/cookiecutter: A cross-platform command-line utility that creates projects from cookiecutters (project templates), e.g. Python package projects, C projects. which lets you do templated templates 
Took this an opportunity to use rust while making an useful application: GitHub - jonringer/nix-template: Make creating nix expressions easy
I’ll be working on this while on a family vacation.
Ideally it will be a tool for advanced users to not have to constantly create cookie-cutter expressions. And for newbies, it can be a useful learning tool:
$ nix-template python -pname requests -f pypi pkgs/development/python-modules/
Generating python expression at pkgs/development/python-modules/requests/default.nix
For an addition to nixpkgs as a python package, please add the following to pkgs/top-level/python-packages.nix:
requests = callPackage ../development/python-modules/<PNAME> { };
For an addition to nixpkgs as a python application, please add the following to pkgs/top-level/all-packages.nix:
requests = python3Packages.callPackage <PATH_FROM_CLI> { };
# pkgs/development/python-modules/requests/default.nix
{ lib, buildPythonPackage, fetchPypi }:
buildPythonPackage rec {
pname = "requests";
version = "<changeme>";
src = fetchPypi {
inherit pname version;
sha256 = lib.fakeSha256;
};
pythonImportsCheck = [ "requests" ];
meta = with lib; {
description = "<changeme>";
homepage = "https://github.com/<owner>/requests/";
license = license.<changeme>;
maintainer = with maintainers; [ <maintainer-name> ];
};
}
I’ll make a more official announcement once it works for python and stdenv. Should also be easy to extend to new frameworks as it will be a glorified string concatenation at a certain point.
Just as a random idea, and for python as an example, it would be neat if the tool went slightly further and checked setup.py and automatically added the needed propagatedBuildInputs from requires. It seems like even just naively string matching against pythonPackages would’ve gotten all the inputs needed for requests. It maybe risks bloating derivations on accident, or leading users astray, or just being out-of-scope for what you have in mind.
BTW: Thanks for making it, I know I’ll use it.
Maybe in the future, short term i would just like something that allows for me to save on typing; as the majority of scaffolding is shared in a given language/framework.
Python might not be a great example. You’re able to specify configuration through a setup.py, pyproject.toml, a setup.cfg. Not to mention there’s usually needs to scope some package to given interpreter version etc.
However, with the --comments option, I hope to generate a much more lengthy expression where I give examples of how to determine dependencies, and scope packages to interpreter versions, etc.
Consider following the scaffold mentioned here https://www.reddit.com/r/NixOS/comments/8tkllx/standard_project_structure/
I really like the separation of files.
I wasn’t aware of this, but I think the majority of new contributions to nixpkgs follow this.
nix flake init allows you to initialize a project from a template. But we don’t have many templates yet.
Example:
$ git init new-project
$ cd new-project/
$ nix flake init -t templates#trivial
$ nix flake show
path:/home/eelco/new-project?narHash=sha256-LhIJ9vSh73GYke9KK0mwCW4Tqj0FXZBMe4Dil9HHslU=
├───defaultPackage
│ └───x86_64-linux: package 'hello-2.10'
└───packages
└───x86_64-linux
└───hello: package 'hello-2.10'
$ nix run
Hello, world!
To get the list of available templates:
$ nix flake show templates
github:NixOS/templates/98414b0eea82c92417fdefcec843e574c61a8cd3
├───defaultTemplate: template: A very basic flake
└───templates
├───simpleContainer: template: A NixOS container running apache-httpd
└───trivial: template: A very basic flake
If you want to contribute templates, please file a PR in the GitHub - NixOS/templates: Flake templates repo.
I’ll have to give it a try. I wasn’t sure if nix flakes were ready enough to begin really moving to. I’m in a weird place where I’m just getting comfortable with pre-flakes nix but I can see how I might quickly surpass my knowledge-base if I were to switch to flakes.
Is there a defaultDevShell analogon to defaultApp and defaultPackage (considerable)? So to make this the target .envrc with the goal to specify a complete dev environment. Or can I put multiple packages in defaultPackage?
Seen similar https://github.com/nix-community/flake-nimble/blob/22e4e490b5d5ad15e78c9225022d0dc43d65af8a/flake.nix#L55-L64
Re flake & flake dev shells: This is a greate resume by @zimbatm Nix Flakes
It mentions nix dev-shell and it looks like this maps to devShell but devShell is not mentioned in the output shema. 
@domenkozar I’d love to see an example using pre-commit-nix with flakes. As mentioned by @zimbatm in his article flake builds are cached and protected from grabage collection (similar to lorri), but it looks like the watching is done by direnv.
Since I had quite some unexpected watches in lorri and unexpected rebuilds, I’d like to try out the more straight-forward idea of watching only flake.nix + flake.lock directly from .envrc as the article implicitly suggests.
With a minimum example on how to incoporate pre-commit-nix into a flake devShell I’d be able to “fight my way throug”.
Just found a reference to devShell in the source: https://github.com/NixOS/nix/blob/master/src/nix/flake.cc#L824
But then I read: https://github.com/NixOS/nix/blob/3f264916dbfe346a71fa4182c9037332ac54f9d9/src/nix/develop.cc#L261 wich sais nix develop drops into the build environment. However the same file makes references to the devShell attribute. 
My expectation would be that devShell reoresents a development environment and not a build environment.
Maybe this needs clarification.
it would be neat if the tool went slightly further and checked
setup.pyand automatically added the needed propagatedBuildInputs fromrequires.
In those flakes, it looks like self has access to useful metadata about the repository. Maybe this can be explored further to that end: templates/simple-container/flake.nix at 98414b0eea82c92417fdefcec843e574c61a8cd3 · NixOS/templates · GitHub
I’m not using flakes and don’t intend to until there’s a Nix release.
I’m focused on creating content for newcomers and getting them to use unreleased Nix to use experimental features is going to only scare them away.