feat(registry): adds reference to python-nix-template

[cameronraysmith]

• reference a python nix template in the registry
• workaround for om init may not preserve file permissions when instantiating templates #429 in
  • fix(direnv): migrate set-git-env to shell application sciexp/python-nix-template#18
• workaround for om init does not replace strings under matching directory name #425 in
  • feat(monorepo): use hierarchical workspace layout sciexp/python-nix-template#19 (comment) and
  • sciexp/python-nix-template@b7c3ddc

based on #424 (comment)

• provide a minimal functional "hello-world" default template that contains a one-to-one mapping to the source code in https://github.com/srid/haskell-template/blame/master/src/Main.hs importing relevant python libraries required to achieve this
• create a template-specific justfile that removes all recipes only pertaining to developing the template repository and not to using the generated template instances

[srid]

Interesting. Your Python template git repo works (direnv loads), but om init generated template does not (direnv fails; screenshot below).

[srid]

Also, is it possible to have a minimal template in the style of https://github.com/srid/haskell-template ?

[cameronraysmith]

but om init generated template does not (direnv fails; screenshot below).

direnv fails because the template instantiation doesn't preserve the permissions of the files in the scripts/ folder ( need to also double check that git has it properly checked in ) but I can update the template envrc to avoid using if its not executable...this is used downstream for local testing of container image builds in a manner that's consistent with how it occurs in github actions

It would be better if both were done purely rather than using env vars but this is how it's done upstream in flocken.

The next problem that arises after chmod +x ./scripts/set-git-env.sh is

#425

See the ASCII cast there. It also shows the file permission preservation issue, but I've now separated that from #425 into

• om init may not preserve file permissions when instantiating templates #429

[cameronraysmith]

Also, is it possible to have a minimal template in the style of https://github.com/srid/haskell-template ?

I will look more closely at the current differences, but which aspects would you have in mind to trim out of the current draft of the python template? I am open to it, especially if we just have multiple templates, but the intent is for one of them to be fairly opinionated.

[srid]

Ah okay, I haven't looked at your other issues yet.

---

I will look more closely at the current differences, but which aspects would you have in mind to trim out of the current draft of the python template?

How about creating a new template that's basically "Hello world" and nothing else? It would provides a devShell that is aware of dependencies specified in project, and a just run that runs the app (ideally even reloads if the .py files change) including nix build or nix run that builds/runs the fully nixified Python program? The opinionated stuff can be on a different template.

An idea behind om init registry is to have one primary template for each language that provides minimal but essential stuff, and add more (like the opinionated ones) and supplemental ones.

[cameronraysmith]

Ah okay, I haven't looked at your other issues yet.

Thanks for pointing out the problem.
I hadn't properly separated #429 from #425 yet.

---

I will look more closely at the current differences, but which aspects would you have in mind to trim out of the current draft of the python template?

How about creating a new template that's basically "Hello world" and nothing else? It would provides a devShell that is aware of dependencies specified in project, and a just run that runs the app (ideally even reloads if the .py files change) including nix build or nix run that builds/runs the fully nixified Python program? The opinionated stuff can be on a different template.

Yes it makes sense to at least have a default template with almost no source code so that anyone can start with a blank canvas and a second (or any number of additional) template(s) that require(s) specifying you'd like to adopt a few more conventions beyond nix alone.

An idea behind om init registry is to have one primary template for each language that provides minimal but essential stuff, and add more (like the opinionated ones) and supplemental ones.

Definitely.

Many thanks for omnix and your input.
I will mark this as a draft until I push workarounds for the two issues and a default template with simplified source code.

[cameronraysmith]

Updated #424 (comment) noting workarounds for referenced issues.
Of note, having refactored python-nix-template as a hierarchical monorepo, only the root package, which contains minimal "hello world" source code is now instantiated by default and users can opt-in if they so choose to including a second workspace package that briefly illustrates utilization of functional effects and runtime type-checking in python.

[cameronraysmith]

Actually, testing

om init github:sciexp/python-nix-template/acac2f858 -o pnt-new

in which the package is renamed but other values are left as defaults reveals the workaround for #425 in sciexp/python-nix-template#19 (comment) only covers the source code but still suffers from

pytest error due to failure to replace strings associated to the package name in files below a folder that is also renamed

❯ pytest
==================================================================================== test session starts =====================================================================================
platform darwin -- Python 3.12.9, pytest-8.3.5, pluggy-1.5.0
rootdir: ~/projects/pnt-new
configfile: pyproject.toml
testpaths: src/pnt_new/tests
plugins: cov-6.0.0, hypothesis-6.127.6, xdoctest-1.2.0
collected 0 items / 1 error

=========================================================================================== ERRORS ===========================================================================================
______________________________________________________________________ ERROR collecting src/pnt_new/tests/test_main.py _______________________________________________________________________
ImportError while importing test module '~/projects/pnt-new/src/pnt_new/tests/test_main.py'.
Hint: make sure your test modules/packages have valid Python names.
Traceback:
/nix/store/wwqdmdr2f5wrjnsjs64bny8df471rh9b-python3-3.12.9/lib/python3.12/importlib/__init__.py:90: in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
src/pnt_new/tests/test_main.py:1: in <module>
    from python_nix_template import main
E   ModuleNotFoundError: No module named 'python_nix_template'

---------- coverage: platform darwin, python 3.12.9-final-0 ----------
Name                             Stmts   Miss  Cover   Missing
--------------------------------------------------------------
src/pnt_new/__init__.py              2      1    50%   2
src/pnt_new/tests/__init__.py        0      0   100%
src/pnt_new/tests/test_main.py       8      7    12%   4-14
--------------------------------------------------------------
TOTAL                               10      8    20%

================================================================================== short test summary info ===================================================================================
ERROR src/pnt_new/tests/test_main.py
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! Interrupted: 1 error during collection !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
====================================================================================== 1 error in 0.43s ======================================================================================

for the tests. The src/python-nix-template folder is correctly renamed to src/pnt-new but the instances of the python-nix-template or python_nix_template strings that are included in the template string replacement (to pnt-new or pnt_new respectively in this case) that should include targeting the files inside that folder are skipped.

Perhaps somewhere the string replacement should be organized in such a manner that it performs a pass restricted to targeting files before a pass that is allowed to target directory names. The behavior suggests this is somehow happening in the opposite order and if a directory name has been replaced all the contents of all the files below it are ignored as candidates for string replacement.

For now we workaround this using relative imports in the simple "hello world" package test.

[cameronraysmith]

This is at

nix --accept-flake-config run github:juspay/omnix -- \
init github:sciexp/python-nix-template/b7c3ddcb2 -o pnt-new

in the omnix-registry lockfile fdd4b27

I believe omnix uses a cache if you've previously executed and do not pin up a new version of a template e.g. github:sciexp/python-nix-template/b7c3ddcb2 vs just github:sciexp/python-nix-template.

[cameronraysmith]

I suppose

nix --accept-flake-config run github:cameronraysmith/omnix/registry-python -- \
init -o pnt-new

is a better test for this PR's particular lockfile update, though it rebuilds omnix from scratch since I imagine it isn't able to hit a relevant cache given the changes

❯ nix --accept-flake-config run github:cameronraysmith/omnix/registry-python -- \
init -o pnt-new
❄️  nix -j auto eval --json '/nix/store/5bfmxzdd2f5flikf548h05fwpnank3i7-om-init-registry#registry' --quiet --quiet️
? Select a flake
  rust-nix-template
> python-nix-template
  haskell-flake
  nixos-unified-template
  haskell-template
[↑↓ to move, enter to select, type to filter]
> Select a flake python-nix-template
❄️  nix -j auto eval --json '/nix/store/d3v03rxgf691rbpqkclyawm29j2zvb54-source#om' --quiet --quiet️
Automatically choosing the one template available: python-nix-template
? Name of the Python package (kebab-case)
...

Otherwise it seems to work as expected; however,

How do you select a registry template non-interactively?

It fails if I just pass python-nix-template into the flake parameter rather than waiting to select interactively (which does work as expected). Maybe this is in the docs but it wasn't immediately apparent to me despite the presence of the global --non-interactive option, which only seems to apply after the interactive registry template selection has been completed.

[cameronraysmith]

Converting back to draft as it will be more natural to use a flat than hierarchical monorepo layout so that the template CI workflows will better function in either case of including just a single vs multiple packages in the monorepo.

[cameronraysmith]

An approximation to

python-nix-template test

rm -fr pnt-new && \
nix --accept-flake-config run github:juspay/omnix -- init github:sciexp/python-nix-template/main -o pnt-new --non-interactive --params '{
  "package-name-kebab-case": "pnt-new",
  "package-name-snake-case": "pnt_new",
  "include-functional-package": false,
  "git-org": "pnt-new",
  "author": "PntNew",
  "author-email": "[email protected]",
  "include-vscode": true,
  "include-github-ci": true,
  "include-flake-template": false
}' && \
cd pnt-new && \
git init && \
git commit --allow-empty -m "initial commit (empty)" && \
git add . && \
nix run .#fix-template-names -- python-nix-template && \
nix run nixpkgs#uv -- lock && \
direnv allow

...

After that completes then just run

pytest

now runs in the ci of python-nix-template.

If you test it locally, note it should automatically recover from

this error

error:
       … while calling the 'derivationStrict' builtin
         at <nix/derivation-internal.nix>:34:12:
           33|
           34|   strict = derivationStrict drvAttrs;
             |            ^
           35|

       … while evaluating derivation 'pnt-new-3.12'
         whose name attribute is located at /nix/store/vdyq3cl640n39sclkc8br4xgd09fdj2w-source/pkgs/stdenv/generic/make-derivation.nix:375:7

       … while evaluating attribute 'UV_PYTHON' of derivation 'pnt-new-3.12'

       (stack trace truncated; use '--show-trace' to show the full, detailed trace)

       error: internal error: accessed dependencies from pyproject.nix project, not uv.lock

[srid]

I will look more closely at the current differences, but which aspects would you have in mind to trim out of the current draft of the python template?

How about creating a new template that's basically "Hello world" and nothing else? It would provides a devShell that is aware of dependencies specified in project, and a just run that runs the app (ideally even reloads if the .py files change) including nix build or nix run that builds/runs the fully nixified Python program? The opinionated stuff can be on a different template.

Yes it makes sense to at least have a default template with almost no source code so that anyone can start with a blank canvas and a second (or any number of additional) template(s) that require(s) specifying you'd like to adopt a few more conventions beyond nix alone.

No, what I meant was to create a minimal template that is still functional, as in nix run prints "Hello world" (it does have source code; see here), and nix develop gives you a fully functional development environment, with project's dependencies loaded (as IDE, like VSCode, "just works".

I recommend taking a look at both

• https://github.com/srid/haskell-template
• https://github.com/srid/rust-nix-template

The Haskell program is just hello world,

Yet, it specifies some external library dependencies to demonstrate that they are readibly available in nix develop shell:

And the just targets are fairly simple and minimal (pertaining only to that language stack, here hoogle, repl and ghcid) as opposted to being a kitchensink.

Does it make sense? Can you think of what the most minimal yet functional Python template would look like?

[cameronraysmith]

How about creating a new template that's basically "Hello world" and nothing else?

This is what I was responding to and did indeed provide in what you get with the default parameters I've embedded in a one-liner in #424 (comment).

Does it make sense? Can you think of what the most minimal yet functional Python template would look like?

minimal yet functional Python template is what I had prior to responding to your point above. I thought you meant truly minimal "Hello world" not minimal + functional, since the latter is essentially what was already there modulo extra recipes in the justfile. I will have to think about exactly what this new category you suggest really boils down to since it is so close to what I initially submitted.

And the just targets are fairly simple and minimal (pertaining only to that language stack, here hoogle, repl and ghcid)

I hadn't thought about a separate justfile for the template, but can certainly figure out a way of removing the recipes that are only relevant to developing the template itself. There actually aren't nearly as many of those as you might think because I'm providing support for the two most widely used package management ecosystems in python via both uv and pixi. Of course some of the secrets management recipes could go.

as oppos[t]ed to being a kitchensink

yes this would mean providing another justfile that removes all the recipes that only pertain to developing the template repository itself

will mark this as draft again until I have a chance to think about how to work toward what you're interested in.

There might be a bit of a gap in time here as the current version https://github.com/sciexp/python-nix-template/tree/v0.1.0 works fairly well for our purposes aside from the workarounds for the omnix issues I have posted. Do let me know if any of those turn out to be the result of user error.

Many thanks for your review as it will help to ensure we eventually arrive at a clean base template to include in the registry!

[cameronraysmith]

based on #424 (comment)

• provide a minimal functional "hello-world" default template that contains a one-to-one mapping to the source code in https://github.com/srid/haskell-template/blame/master/src/Main.hs importing relevant python libraries required to achieve this
• create a template-specific justfile that removes all recipes only pertaining to developing the template repository and not to using the generated template instances

let me know: If those tasks from the revised OP were completed as described, do you think we'd be significantly closer to synchronizing our understanding of what would be most useful?

[cameronraysmith]

The

CI https://github.com/juspay/omnix/actions/runs/13745303957/job/38449517038?pr=424 error

  ---- command::init::om_init stdout ----
  🕍 Testing template: /nix/store/zdwrzskc47c7ic36jix50b3vpcb51k00-source
  🕍 Testing template: /nix/store/vzvw6cy4gjcj1dp28z6pkf0qqycnp5h6-source
  🧪 [/nix/store/vzvw6cy4gjcj1dp28z6pkf0qqycnp5h6-source#python-nix-template] Running test: default
  PathAssert nix/modules/template.nix; exist? (false) in "/tmp/nix-shell.T43KED/.tmp4FhMxs/output"
  PathAssert .vscode; exist? (true) in "/tmp/nix-shell.T43KED/.tmp4FhMxs/output"
  PathAssert pyproject.toml; exist? (true) in "/tmp/nix-shell.T43KED/.tmp4FhMxs/output"
  PathAssert flake.nix; exist? (true) in "/tmp/nix-shell.T43KED/.tmp4FhMxs/output"
  PathAssert .github/workflows/ci.yaml; exist? (true) in "/tmp/nix-shell.T43KED/.tmp4FhMxs/output"
  Error: Command error: Process exited unsuccessfully. exit_code=Some(1) stderr=warning: ignoring untrusted flake configuration setting 'extra-substituters'.
  Pass '--accept-flake-config' to trust it
  warning: ignoring untrusted flake configuration setting 'extra-trusted-public-keys'.
  Pass '--accept-flake-config' to trust it
  error (ignored): error: end of string reached
  error:
         … while calling the 'derivationStrict' builtin
           at <nix/derivation-internal.nix>:34:12:
             33|
             34|   strict = derivationStrict drvAttrs;
               |            ^
             35|
  
         … while evaluating derivation 'python-nix-template-3.12'
           whose name attribute is located at /nix/store/vdyq3cl640n39sclkc8br4xgd09fdj2w-source/pkgs/stdenv/generic/make-derivation.nix:375:7
  
         … while evaluating attribute 'NIX_PYPROJECT_DEPS' of derivation 'python-nix-template-3.12'
  
         (stack trace truncated; use '--show-trace' to show the full, detailed trace)
  
         error: path '/nix/store/i6dpfqq0lwivlbmw4047yv675ja50ss5-source/packages/pnt-functional' does not exist

results from the package root uv.lock referencing both monorepo packages by default, but ending up instantiated here, perhaps using all the default template's default values, without a copy of that second monorepo package source folder. Two questions:

1. Since this occurs during build/test of omnix itself, what's the minimal equivalent nix command required to run this test in the python-nix-template CI?
2. Do you have examples analogous to haskell-template / rust-nix-template that provide more than just one template output? It's not clear to me whether I should be thinking about hosting a templates folder that contains multiple copies starting all the way at the what is currently my template repo root.

[srid]

Yes, those tasks look good to me.

I just initialized your template from that linked comment, by running:

rm -fr pnt-new && \
nix --accept-flake-config run github:juspay/omnix -- init github:sciexp/python-nix-template/main -o pnt-new --non-interactive --params '{
  "package-name-kebab-case": "pnt-new",
  "package-name-snake-case": "pnt_new",
  "include-functional-package": false,
  "git-org": "pnt-new",
  "author": "PntNew",
  "author-email": "[email protected]",
  "include-vscode": true,
  "include-github-ci": true,
  "include-flake-template": false
}' && \
cd pnt-new && \
git init && \
git commit --allow-empty -m "initial commit (empty)" && \
git add . && \
nix run .#fix-template-names -- python-nix-template && \
nix run nixpkgs#uv -- lock && \
direnv allow

This created the following layout:

• What's all those *conda_spec.txt files? Are they critical for Hello World projects?
• Why is there nodeJS package.json (two of them in fact) or yarn.lock? Are they critical for a Hello World Python program?
• What's pixi.lock?
• Why are there two pyproject.toml?
• Do we need two README.md?
• packages/pnt-new/src/pnt_new/__init__.py - Does this path have to be this long?
• Can we get rid of tests (packages/pnt-new/src/pnt_new/tests)?
• justfile: Are these 60+ targets critical for a Hello World Python project? Or does 1 or 2 suffice?
• Are you sure you need all the modules in ./nix/modules/*.nix? Which of them are critical to Hello World project?

Hopefully that gives you some concrete idea. I'd also suggest that you start from scratch, from a new empty repo and add files only as necessary, instead of trimming the existing one.

[cameronraysmith]

• What's all those *conda_spec.txt files? Are they critical for Hello World projects?
• What's pixi.lock?
• Why are there two pyproject.toml?
• Do we need two README.md?

For better or worse there are two package managers in the python ecosystem with widespread use: PyPI and Conda. All widely used tools release to both.

uv, which builds PyPI packages, has functioning support for workspaces as mirrored in uv2nix and so it gets one lockfile in the repo root that applies to each of the packages in the packages folder. The repo root pyproject.toml is just a marker for a workspace and then each of the pyproject.toml files in each subfolder of the packages folder supports the build of just that package.

Although pixi, which builds Conda packages, is working on mirroring uv's workspace support, it's not ironed out yet so each of the subdirectories of packages is treated as an independent Conda package. This is where the pixi.lock files come from.

Within the conda ecosystem, there are 3 distinct and widely utilized clis.
The pixi.lock files work with the pixi cli, all the files in the conda/ subfolders are lockfiles required by the conda/mamba clis which are still dominant in the conda-forge package release ecosystem though these will eventually be sunset and removed.

Specifically focusing on the question about two files here vs why they exist at all above

• Why are there two pyproject.toml?
• Do we need two README.md?

The two are because this is how uv workspaces are specified and instantiated

https://docs.astral.sh/uv/concepts/projects/workspaces/

see uv2nix's test fixtures

https://github.com/pyproject-nix/uv2nix/blob/61f6313f438656b57e653b96301fce14a7eed82e/lib/fixtures/workspace-flat/packages/pkg-a/pyproject.toml
https://github.com/pyproject-nix/uv2nix/blob/61f6313f438656b57e653b96301fce14a7eed82e/lib/fixtures/workspace-flat/packages/pkg-b/pyproject.toml

• Why is there nodeJS package.json (two of them in fact) or yarn.lock? Are they critical for a Hello World Python program?

The "release" key in the package.json's are one of the supported ways of providing a configuration file that contains what is required to automate release of each of the relevant versions of each of the monorepo packages using semantic-release in the python-nix-template github actions workflows to be included in the template: https://github.com/sciexp/python-nix-template/blob/7e21527def1cfd83cec1c6b7dc6acb3fc4ff084b/.github/workflows/package-release.yaml#L153-L170
The yarn.lock is just like all the other package manager lock files like flake.lock, uv.lock. pixi.lock, but for the package.json files. Here we have another tool that supports monorepos with multiple packages so we only need one in the repo root.

• packages/pnt-new/src/pnt_new/__init__.py

Not sure what the questions is here. I suspect you think maybe the folder names are a bizarre duplication, but they are not. This is essentially mandated by the structure of a flat uv workspace as exemplified, for example, in this uv2nix test fixture:

https://github.com/pyproject-nix/uv2nix/blob/61f6313f438656b57e653b96301fce14a7eed82e/lib/fixtures/workspace-flat/packages/pkg-a/src/pkg_a/__init__.py
https://github.com/pyproject-nix/uv2nix/blob/61f6313f438656b57e653b96301fce14a7eed82e/lib/fixtures/workspace-flat/packages/pkg-b/src/pkg_b/__init__.py

What you have copied above is the exact same form as

packages/pkg-a/src/pkg_a/__init__.py
packages/pkg-b/src/pkg_b/__init__.py

from uv2nix but applying to one of the two packages currently included in python-nix-template.

If you are asking what an __init__.py file is in general, this is required for any folder to be considered to contain a python package. In that sense, those files are absolutely essential.

• Can we get rid of tests (packages/pnt-new/src/pnt_new/tests)?

We could, but my criterion for a successful template instantiation was being able to successfully execute pytest and have a minimal test suite working to then begin iterating on with the new package.

• justfile: Are these [50+] targets critical for a Hello World Python project? Or does 1 or 2 suffice?

yes this would mean providing another justfile that removes the recipes that only pertain to developing the template repository itself; but more are required than you might imagine to clearly support both uv and pixi, which is considered a requirement for python projects that intend to make themselves available for wide adoption.

it could probably easily be reduced to 35. 1 or 2 wouldn't make much sense, and you'll forgive me for getting the sense you're heading in the direction of hyperbole here.

• Are you sure you need all the modules in ./nix/modules/*.nix? Which of them are critical to Hello World project?

Well, once

• om init does not replace strings under matching directory name #425
• om init may not preserve file permissions when instantiating templates #429

are resolved, one or two of them that serve as workaround shell applications could certainly go. We could discuss this further if some of the more pertinent issues above are resolved.

The only particularly "non-standard" nix file aside from the two shell applications, containers.nix, is used to support building container images from our nix packages in such a manner that the resulting images could be used to run the application on any oci runtime, in kubernetes, etc.

[cameronraysmith]

I think a good fraction of your surprise at the apparent complexity of python-nix-template factors into two distinct categories:

1. complexity from the python ecosystem that trickles down into attempting to provide developers what they need to be able to shift all of that into background automation
2. complexity of the particular detailed manner in which all of those issues are handled thus far in python-nix-template

If you don't do much to handle 1 for prospective users, then there's no point in yet another python template.
My estimate is that this is closer to 70/30 than 25/75 or even 50/50.

As such, while we can certainly put in effort to reduce the complexity of issues arising from factor 2 (~30%), we won't be able to do much about factor 1 that doesn't significantly reduce the value of the prospective service python-nix-template intends to provide.

On the other hand, we definitely would love to figure out as much of a middle-ground as possible to allow relatively less-seasoned users to slowly scale up the usage of the set of features python-nix-template offers, and, from this perspective, we hope to be able to find a reasonable balance here working with that 30% added complexity that we might have the latitude to better optimize without creating a template that is ONLY useful for those who want to try out "hello world" and leaves the people dealing with the complicated reality of the underlying ecosystem hanging out to dry.

[cameronraysmith]

I'd also suggest that you start from scratch, from a new empty repo and add files only as necessary, instead of trimming the existing one.

It's quite unlikely we'd be able to consider doing this. If you feel strongly about this, we should probably consider closing the PR for now and revisiting at some point in the future when that could be tenable.

I'd give you some opportunity to think a bit more about what I've said above before responding further.
Otherwise, feel free to suggest closing if you think it will be impossible to find a middle ground.

It may be that a good approach to

Do you have examples analogous to haskell-template / rust-nix-template that provide more than just one template output? It's not clear to me whether I should be thinking about hosting a templates folder that contains multiple copies starting all the way at the what is currently my template repo root.

could help achieve both goals so that the FIRST layout tree one receives in the simplest default template instantiation is MUCH simpler than what we currently have and the complexity could be toggled on feature-by-feature as needed. That's probably the ideal outcome in my view.

[srid]

I'll take a look at this later, but as quick response: omnix registry is rather nascent and is still evolving (#282, #336, #314). I'd like to support 3rd party registries¹, so om init provides minimal defaults for various stacks (like Python hello world), but also provides 'community' registries that includes templates like this one.

Footnotes

1. Technically, this is partially supported, as you can run om init <registry-url>, for e.g.: om init -o /tmp/test "github:juspay/nixos-unified-template" provides 3 templates to choose from. ↩

[srid]

Do you have examples analogous to haskell-template / rust-nix-template that provide more than just one template output?

Yes, see the footnote of parent comment.

The 3 templates are defined here, including tests for them: https://github.com/juspay/nixos-unified-template/blob/main/modules/flake/template.nix

[cameronraysmith]

omnix registry is rather nascent and is still evolving (#282, #336, #314). I'd like to support 3rd party registries1, so om init provides minimal defaults for various stacks

Yes I totally understand.
Please feel free to take your time as it is (un)available ;) for this project.

Many thanks again for all of your work in the nix ecosystem and omnix itself.
We have learned a tremendous amount from you, benefited significantly from your work, such as via use of omnix illustrated here, and hope we can contribute to bridging its utility to a wider audience in one way or another.

[cameronraysmith]

Do you have examples analogous to haskell-template / rust-nix-template that provide more than just one template output?

Yes, see the footnote of parent comment.

The 3 templates are defined here, including tests for them: https://github.com/juspay/nixos-unified-template/blob/main/modules/flake/template.nix

Oh yes. Of course, I have used this in my personal nix-config, but this was initially adapted around the time we were discussing juspay/nixos-unified-template#7 and before you had nixos-unified-template in its currently, and very nicely, factored form. As such, I forgot nixos-unified-template obviously now represents a scenario with multiple omnix templates. This may help me figure out how to refactor python-nix-template to be able to achieve the mutual goals we agree on from above.

I certainly understand where you're coming from about having the default template for any language/framework in omnix-registry be quite minimal. I just want to be able to include the minimal template instance in a repo where people can quickly toggle on the additional features as desired because I know the vast majority of users will EVENTUALLY realize they need them or could benefit from them and nobody should actually be wasting their time sorting any of these things out multiple times in slightly different ways if they can at least take a quick look at one working approach via a feature toggle they can adapt as they need for their own purposes.