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 template string replacement may fail on file trees below replaced directory names #425 in
  • feat(monorepo): use hierarchical workspace layout sciexp/python-nix-template#19 (comment) and
  • sciexp/python-nix-template@b7c3ddc

[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.