python310Packages.fasm: init at 0.0.2.post100

[hansfbaier]

Description of changes

added nix packaging for fasm
This PR depends on https://github.com/NixOS/nixpkgs/pull/251333/commits
If somebody else wants to maintain this, please change the maintainer.

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 23.11 Release Notes (or backporting 23.05 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

[fabaff]

The upstream repo contains tests. unittestCheckHook should be used. If they are not part of the source from PyPI then the source from GitHub should be used.

Please also add pythonImportsCheck.

[fabaff]

Using hash with a SRI hash is the preferred way nowadays.

[hansfbaier]

@fabaff I applied your review notes, and built the packages.
But I noticed something strange: the output derivation only contains the executable binaries,
but no python code for the fasm python library.
For example if I install the python package locally with pip, I also get the following files:

~/.local/lib/python3.10/site-packages/fasm $ find .
.
./parser
./parser/antlr_to_tuple.pyx
./parser/fasm.tx
./parser/textx.py
./parser/antlr.py
./parser/__pycache__
./parser/__pycache__/__init__.cpython-310.pyc
./parser/__pycache__/textx.cpython-310.pyc
./parser/__pycache__/antlr.cpython-310.pyc
./parser/__init__.py
./tool.py
./output.py
./version.py
./__pycache__
./__pycache__/tool.cpython-310.pyc
./__pycache__/__init__.cpython-310.pyc
./__pycache__/output.cpython-310.pyc
./__pycache__/version.cpython-310.pyc
./__pycache__/model.cpython-310.pyc
./__init__.py
./model.py

Where would those files go in nix?

[hansfbaier]

@fabaff I probably built the wrong derivation:
I used in my local copy of nixpkgs:

$ nix repl
:lf .
:bl outputs.legacyPackages.i686-linux.fasm

But I probably should have built something under outputs.legacyPackages.i686-linux.python310Packages.
The problem is, I can't find fasm there.
How would I build this package?

[chuangzhu]

The problem is, I can't find fasm there.

You should add an entry in pkgs/top-level/python-packages.nix:

+  fasm = callPackage ../development/python-modules/fasm { };

[jleightcap]

This draft is good start, but a valid method of testing:

1. add fasm to python-packages
2. nix build .#python3Packages.fasm

Your use of the REPL is interesting, but unfortunately didn't execute the
package you had written here. I'm not positive but I think you might have been
building the other fasm (flat assembler) existing in nixpkgs. Hence there
being no python libraries in the result.

I've taken a stab at packaging this in an out-of-band repo for the time being:
openXC7/toolchain-nix#6

The upstream being inactive with a failing test suite also doesn't bode well for
this package being upstreamed, at the moment.

[hansfbaier]

@jleightcap I pushed your packaging effort here. It will need to be adapted to use the openxc7 fork instead.