Open Pegasust opened 1 year ago
Ran into this same issue today as well, but not with Python.
It looks like if the package
uses pname
/version
(vs. just name
) and thus has a name
of ${pname}-${version}
the entrypoint generated script can't find it as it drops the version
.
I think it's related to the fact that the operable wraps by using ${package.name}
at one point, but I got a little lost in the weeds trying to trace it thru the various blockTypes and functions.
Sorry for the delay in looking into this and thanks for the report!
The issue, so to speak lies in this line and derives indeed from the implementation choices of getExe
:
# including this and
nixand
stdtells me to remove either
meta.tagsor
tag``
This has fortunately just been fixed.
For my own better understanding:
runtimeScript = ''
hypercorn my.backend:app --bind '0.0.0.0:10140' --worker-class uvloop
'';
Which of the code in the flake brings my.backend:app
into the python path? (I'm not 100% familiar, atm).
Add check phase for mkStandardOCI that checks for symlink integrity. Might be doable at the phase of writing /bin/entrypoint and before using nix2container to write .json manifest
That is a good idea, however it also seems to me that this python case could have maybe a better designed interface?
Just ideas, but why not e.g. mkStandardOCIWithHypercorn
? For my taste # nix/ops/oci.nix
could be an even shorter file. Would creating a library of tool-specific mkStandardOCI
-interfaces with all the hard learned expriences already codified be a good idea?
I'm musing about this because currently, the operable's package
is not even put into the PATH
environmet, but I can see how different runtime enviroenments would like to see that package made available in their relevant environment, whether that be PATH
or PYTHONPATH
or anything else. It would be somewhat scoped to scripted languages.
hypercorn
+ poetry2nix
The part that brings in (I guess $PYTHONPATH, or allow for python -m my.backend
) is workspace_app.dependencyEnv
, which is
workspace_app = poetry2nix.mkPoetryApplication {
projectDir = workspace_root;
}.dependencyEnv;
and pyproject.toml
that uses poetry. Poetry2nix takes care of taking these dependencies and either build them, or acts as Nix .whl
broker via poetry.lock
for preferWheels = true
builds.
# minimal pyproject.toml
[tool.poetry]
name = "acme-monolith"
[tool.poetry.dependencies]
python = "^3.10"
databases = "^0.7"
hypercorn = "^0.14.3"
uvloop = "^0.17.0"
# This requires the path for `./my/backend.py:app` or `./my/backend/__init__.py:app`
# Though, out-of-the-box top-level package detection from `poetry` should cover most
# cases, I'm putting this here for explicitness
[[tool.poetry.packages]]
include = "my"
[build-system]
requires = ["poetry-core"]
build-backend = "poetry.core.masonry.api"
For context/archival purposes, .dependencyEnv
sort of just calls inputs.nixpkgs.python.mkEnv
, which calls inputs.nixpkgs.buildEnv
or something similar then calls it a day, so the original package name is not passed through to .dependencyEnv
.
I'm unsure which specific part injects onto PYTHONPATH
, by inspecting the built artifacts, it looks like the python executable is wrapped
As @jboyens pointed out, this issue is unfortunately not specific to ${poetryApplication}.dependencyEnv
, but is arose from some common patterns when it comes to interpreted languages, so this issue could probably be addressed via common pattern like mkStandardOCIFromInterpretedEnvironment
, though feel free to suggest shorter names.
If there are some framework-specific nitpicks, I do think there's novelty in keeping mkStandardOCI
having a low-level interface with some basic default configuration that covers 80%+ cases, with integrations having their own modules or transformed like (lib.dev.mkNixago lib.cfg.lefthook)
into something like (mkStandardOCIWith oci.interpretedEnv)
, and add some recipe docs, linking to this issue. My only concern is at some point, our API change, and the recipe docs effectively points to some out-dated way to solve this
# including this and nix and std tells me to remove either meta.tags or tag
This has fortunately just been fixed.
Thanks for this!
Also taking a look on https://github.com/divnix/std/pull/331
Fixed in https://github.com/divnix/std/pull/331
I have a pretty standard poetry2nix web application that I wrap on its environment derivation using
hypercorn
. The built OCI fails to detect the correct binary location because it relies onlib.getExe
.mkOperable
works as expected, though.Symptoms
I don't have the exact error that throws from Docker engine. It should be something along the line of Docker container not being to start up because
/bin/entrypoint
not found.If you have access to
ls
(I use Python'sos.listdir
because I'm too lazy to build a dev layer), You would see that/bin/entrypoint
exists, but it is a broken symlink.One example output is
Workaround
Nix flakes and its workaround variant
Some more insights from build artifacts
Thoughts
mkPoetryEnv
.mkPoetryEnv
does provide a simple way to override onto a simplername
, whereas withdependencyEnv
overwrites the declaredname
.Requests
mkStandardOCI
that checks for symlink integrity. Might be doable at the phase of writing/bin/entrypoint
and before usingnix2container
to write.json
manifest