Repository navigation
Nix packaging - #256
Nix packaging#256Lillecarl wants to merge 1 commit into
Conversation
|
@holmboe I'm open to walking through the complete changeset 1on1 once/if you have a moment to spare :) |
| build-system = [ hatchling ]; | ||
| dependencies = [ | ||
| installShellFiles | ||
| # deps |
There was a problem hiding this comment.
Is it possible, and advisable, to get this list fromTOML somehow?
There was a problem hiding this comment.
It's possible with https://pyproject-nix.github.io/uv2nix I've been packing up https://github.com/dynamist/weav with uv2nix so you'll be able to see the different approaches (It's more complex but it also uses uv.lock to fetch deps which is more correct).
When packaging with the nixpkgs Python builders it's not recommended however.
There was a problem hiding this comment.
Is this direnv? See T2157 for context and evaluate if this is desirable.
There was a problem hiding this comment.
It is direnv, using direnv is absolutely optional (you don't have to install it and you don't have to approve a projects .envrc if you don't want to). It's not possible to get a Nix environment without executing Nix.
Without direnv you can run either "nix-shell" or "nix develop" but IMO they're slightly worse since they force you into a bash subprocess (which is technically good since you get access to Nix bash builder functions) but it's not nice if you're an alternative shell user. (You can hack your way around that by exec'ing $SHELL in shellHook).
I think it's worthwhile to revisit T2157 if we're pivoting towards exploring the world of Nix (direnv is authored by numtide which is a Nix consultancy). Static .env files doesn't work when you bring in Nix.
aad4bb5 to
df86bbb
Compare
a7b575d to
e63bef8
Compare
99d9cab to
6a45672
Compare
 |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
| flake-compatish { | ||
| source = ./.; | ||
| overrides = { | ||
| # override nixpkgs with NIX_PATH if available |
There was a problem hiding this comment.
If NIX_PATH has no nixpkgs entry, importing shell.nix or default.nix without supplying pkgs forces this <nixpkgs> override and fails during evaluation. It never falls back to the nixpkgs revision in flake.lock, so the traditional-Nix entry point cannot be used in that environment.
There was a problem hiding this comment.
flake-compatish forces the fallback in a builtins.tryEval block so if doesn't exist it'll use the nixpkgs pinned in flake.lock
There was a problem hiding this comment.
You're right — I missed that flake-compatish evaluates supplied overrides through builtins.tryEval. The <nixpkgs> override is lazy, so when NIX_PATH has no nixpkgs entry, its evaluation fails inside tryEval; resolveOverride returns null, and evaluation proceeds with the locked nixpkgs node. The fallback works as intended, so this comment is not valid.
Tip: You can customize Greptile's behavior for this repo with .greptile/rules.md and .greptile/config.json.
| (python3.withPackages (_: [ | ||
| phabfive.propagatedBuildInputs | ||
| ])) |
There was a problem hiding this comment.
phabfive.propagatedBuildInputs is already a list. Wrapping it in another list passes python3.withPackages a list containing a list, rather than Python packages. Entering the new development shell therefore cannot construct the intended Python environment.
| dependencies = [ | ||
| installShellFiles | ||
| # deps | ||
| anyconfig | ||
| appdirs | ||
| inquirerpy | ||
| jinja2 | ||
| phabricator | ||
| pyyaml | ||
| rich | ||
| ruamel-yaml | ||
| typer | ||
| ]; |
There was a problem hiding this comment.
This list omits click, requests, urllib3, and the Python 3.10 dependency tomli, all declared as direct runtime dependencies in pyproject.toml. The CLI imports click at startup, including when postInstall runs it to generate completions. If these packages are not supplied transitively, the Nix build fails or installed commands lose functionality; those transitive dependencies are not guaranteed.
| patches = [ ./patches/python-phabricator-no-pkg-resources.patch ]; | ||
|
|
||
| build-system = [ setuptools ]; | ||
| dependencies = [ responses ]; |
There was a problem hiding this comment.
The separately exposed phabricator package declares responses here but omits its actual runtime dependency, requests. If a consumer installs this Nix output on its own, it does not receive the dependency phabricator needs to create its HTTP session, even though phabfive may supply it through another route.
pydd reads uv.lock in a recursive-nix planner and builds one node per package, so the Nix code restates no dependency. phabfive installs from its sdist, with no dependency group, and its root adds the shell completions and the agent skill from `phabfive --skill`. The dev shell installs the dev group from the same lock, with phabfive editable over the checkout. Its source holds no code, so an edit does not change its plan. Impure evaluation names the checkout directly. Pure evaluation has no currentSystem, so a shellHook finds it with git. flake.nix holds the outputs. default.nix evaluates the same flake with flake-compatish, in place, and takes nixpkgs from NIX_PATH when it names one. A local nixidae checkout goes in the gitignored overrides.nix. The build needs the experimental features flakes, ca-derivations, dynamic-derivations and recursive-nix, and recursive-nix added to system-features. nix/README.md gives the settings. Assisted-By: Claude Opus 5.5
Packaging phabfive with Nix.
Exposes a flake as well as "traditional Nix" with support for user-supplied nixpkgs instance, nixpkgs from NIX_PATH or the nixpkgs version locked in the flake.