pkg generator

[blaggacao]

Based on real experienced frustration, it would be extremely powerful to have a wrapper to go get, so that when you go get something within a devshell environment, it automatically generates a valid nix package descriptor.

Similar for other languages.

Alternative (less intrusive) UX:

• devshell go get ...
• devhsell pip install ... (with mach-nix)
• ...

Bonus:

-devshell upstream -> generates a PR to nixpkgs with custom packages 😉 — problem nixpkgs folder "chaos" maybe does not provide sufficiently clear metadata

My experience is that it took a very long time to get all tooling set up (one time effort, but who knows if I decide to change tooling tomorrow, on the go).

[zimbatm]

devshell init could be a bit smarter and detect the language of the project.

Having some sort of package generators seems like an interesting idea but it needs to be fleshed out much more.

[blaggacao]

Questions (of the top of my mind without particular breadth or depth):

• What is the canonical way of extending devshell with overlays? (I might have developped one possible answer to that as part of Add FQDN and TLS trust management (example extension) #28)
• What is the UX comand/control flow?
  • GetPackage -> (language native)
  • <- PkgDescribed (nixlang)
  • <- GotPackage (nix build)
    Emulating language native tooling is key and also renders this enhancement idea a 80/20 one: it cannot avoid rough edges and only support some/most of the things.
• nix pkg descriptor templating? -> given the variety in language-specifics of pkg descriptor, templating is probably the way to go over let's say ast composition of some sort (which woudn't probably have tooling support anyway).
• Is a templating collection in scope for devshell or should live apart? What is the maintainance model/workflow? Might those template collections even become a nixpkgs feature?
• What are the supported variants and invariants of a given template respective to their build support implementation? e.g. can we always fetch meta-data from a (github) api or do we need dummy invariants? Should we simplify flags to those that work "most of the time"?
• What might be the criteria for leveraging ecosystem tooling (e.g. mach-nix)?
• What support level cut-off level / trade off is acceptable? How handle non-supported cases on the user interface?
  • <- NotPkgDescribed
  • <- NotGotPackage