So I have made it work as imports. However I had to do some funny things as makeWrapper doesn't have an option to set the interpreter of the executable it is wrapping. Furthermore the source file isn't even set to have the executable permission. While these things could be fixed upstream, I'm sure I'll deal with more of these sorts of things since I'm packaging a lot of scientific stuff and they are not always standards.

@FRidh Could you have a look?

One other thing, this script outputs a log file usually placed in the same location as the script. I changed that so it outputs that script to the current directory. I could also point it to /tmp. Not sure what the convention is.

The psma is just another python module in the same relative directory. What do you mean by putting it into site-packages? The source repo doesn't use setup.py or anything.

No, it indeed doesn't, and they don't have to. However, if one would take your expression, and install it in a profile, they end up with scripts in the root of their profile, instead of under /bin or /lib.

The problem is that the script relies on relative imports and relative paths to the SQL scripts. I'm not sure how to do that with buildPythonApplication or buildPythonPackage.

You don't need to use buildPython* for it. Just create a site-packages folder, and move the modules in there. If you want to use PYTHONPATH, you then add that folder to it.

So I can do this these things.

Use: buildInputs = python3.withPackages (ps: with ps; [ psycopg2 ]);

Then inside the installPhase:

mkdir -p "$out/${python3.sitePackages}"
cp __init__.py "$out/${python3.sitePackages}"
cp load-gnaf.py "$out/${python3.sitePackages}"
cp psma.py "$out/${python3.sitePackages}"
cp -r postgres-scripts "$out/${python3.sitePackages}"

The load-gnaf.py still loads postgres-scripts relatively here: https://github.com/minus34/gnaf-loader/blob/master/load-gnaf.py#L276-L279

We still need something in bin to be load-gnaf I'm guessing? How should that be done? Like this?

sed \
  -i \
  '1s;^;#!/usr/bin/env python\n;' \
  "$out/${python3.sitePackages}/load-gnaf.py"
chmod u+x,g+x,o+x "$out/${python3.sitePackages}/load-gnaf.py"
makeWrapper \
  "$out/${python3.sitePackages}/load-gnaf.py" \
  $out/bin/load-gnaf \
  --set PATH '${stdenv.lib.makeBinPath [ postgis ]}'

Or maybe instead:

cat <<EOF > $out/bin/load-gnaf
#!/usr/bin/env sh
exec ${python3.interpreter} "$out/${python3.sitePackages}/load-gnaf.py"
EOF
chmod u+x,g+x,o+x $out/bin/load-gnaf
wrapProgram 
makeWrapper \
  $out/bin/load-gnaf \
  --set PATH '${stdenv.lib.makeBinPath [ postgis ]}'

(triage) @CMCDragonkai I personally prefer your first option, though I haven't checked whether it actually corresponded to @FRidh's request. The advantage of it over your second option is that you avoid loading one useless file in memory, a priori.

Actually, I think you may even get rid of the sed by wrapping directly the python executable and providing it default arguments set to pointing to the script.

Are there any updates on this pull request, please?

Feel free to take over the PR @mmahut, I'm not working on this atm.

Ok, going to close it for now, if anyone is interesting in taking over, feel free to reopen this.