fix(php plugin): reference php output via explicit flake fragment

[mikeland73]

Summary

Fixes #2788.

The php plugin's generated flake (plugins/php/flake.nix) exports two
packages:

packages.${system} = {
  default = php;
  composer = php.packages.composer;
};

but the plugin (plugins/php.json) referenced them inconsistently — php via the
bare path:{{ .Virtenv }}/flake (i.e. the flake's default output) and
composer via an explicit #composer fragment:

"packages": [
  "path:{{ .Virtenv }}/flake",
  "path:{{ .Virtenv }}/flake#composer"
]

Root cause

Devbox's own flake example documents that a flake exporting more than one
package must be referenced with explicit url fragments, and that the bare
default reference is meant for single-output flakes:

Flakes can export multiple packages. To include specific packages in
devbox.json you can use url fragments (e.g. path:my-flake#my-package) […]
If you only want to export a single package, you can name it default which
allows installation without using url fragment.
— examples/flakes/php/my-php-flake/flake.nix

Relying on the bare default for one of two outputs is fragile. In #2788 this
surfaced as the php binary not being linked into the environment (only
composer appeared under .devbox/nix/profile/default/bin), leaving php
unavailable in the shell.

Fix

• plugins/php/flake.nix: add a named php output alongside the existing
  outputs. default = php is kept for backwards compatibility with anyone
  referencing the flake directly.
• plugins/php.json: reference php explicitly as
  path:{{ .Virtenv }}/flake#php, mirroring the working #composer entry, so
  both plugin packages are resolved the same way. Bump the plugin version
  (0.0.3 → 0.0.4) so cached create_files are regenerated for existing
  projects.

This aligns the php plugin with the documented best practice for multi-output
flakes and with the working examples/flakes/php example, which already
references its php output as path:my-php-flake#php.

How was it tested?

• go build ./... — clean.
• go test ./internal/plugin/... ./internal/shellgen/... ./internal/devconfig/configfile/... — pass.
• Verified the plugin flake template still renders and that the extension-name
  matcher in flake.nix is unaffected (the new #php/#composer refs do not
  match the ^php.*Extensions… pattern, same as before).

Note: the existing testscripts/languages/php.test.txt (which runs devbox run php) exercises both the cached and non-cached php paths and passes on main,
so the failure in #2788 appears to be environment-specific (the reporter was on
devbox 0.16/0.17 with Lix). This change removes the fragile bare-default
reliance that is the most likely cause, and makes the plugin consistent with
devbox's documented multi-output flake usage.

cc @assyrus-favolo (issue reporter) — thanks for the detailed reproduction and
the generated flake.nix in the issue comments, which pinpointed that only the
composer output was making it into the environment.

Community Contribution License

All community contributions in this pull request are licensed to the project
maintainers under the terms of the
Apache 2 License.

By creating this pull request, I represent that I have the right to license the
contributions to the project maintainers under the Apache 2 License as stated in
the
Community Contribution License.

🤖 Generated with Claude Code

https://claude.ai/code/session_011G5YZ3hdoiBSd3T9GGLYox

---

Generated by Claude Code

[Copilot]

Pull request overview

This PR fixes inconsistent flake output referencing in the PHP plugin by ensuring both php and composer are referenced via explicit flake URL fragments, aligning the plugin with Devbox’s documented multi-output flake guidance and addressing issue #2788 (missing php binary in the environment).

Changes:

• Add a named php package output to the generated plugins/php/flake.nix while keeping default for backwards compatibility.
• Update the plugin package list to reference php explicitly via path:{{ .Virtenv }}/flake#php.
• Bump the PHP plugin version to force regeneration of cached create_files content.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File	Description
plugins/php/flake.nix	Exports an explicit php output alongside default and composer to support fragment-based referencing.
plugins/php.json	Updates package references to use #php and bumps plugin version to invalidate cached rendered files.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[assyrus-favolo]

Thank you for looking into this!

[mikeland73]

@claude please review

[claude]

Claude finished @mikeland73's task in 1m 16s —— View job

---

Review

• Gather context (diff, changed files, CLAUDE.md)
• Understand the fix and verify it against the flake.nix / php.json
• Post review feedback

Diff reviewed: git diff origin/main...HEAD — only plugins/php.json (+1/-1) and plugins/php/flake.nix (+5/-0).

Summary

This is a correct, minimal fix. The root cause analysis holds up:

• plugins/php/flake.nix (packages.{{ .System }}) exports both default and composer, but plugins/php.json referenced php via the bare path:{{ .Virtenv }}/flake (the default output) while composer used the explicit #composer fragment. Relying on default resolving to the same derivation as the named php output is fragile and matches the documented guidance in examples/flakes/php/my-php-flake/flake.nix:16-23 ("multi-output flakes should use fragments; default is for single-output flakes").
• The fix adds a named php output (plugins/php/flake.nix:29) and updates plugins/php.json:6 to reference it as #php, mirroring the working #composer entry.
• Checked the other plugins that reference path:{{ .Virtenv }}/flake (mysql.json, mariadb.json, haskell.json) — they only export a single (default) package each, so they don't have this bug and don't need the same treatment.
• The version bump 0.0.3 → 0.0.4 (plugins/php.json:3) is the right way to force create_files cache invalidation for existing projects; I didn't find any other place in the repo hard-coding the old 0.0.3 version.
• php = php; alongside default = php; in the flake is redundant-looking but intentional and harmless (keeps default for direct-reference backwards compatibility while adding the named output the plugin now uses) — the added comment explaining this is good, since the "why" isn't obvious from the code alone.

Minor, non-blocking observations

• testscripts/languages/php.test.txt passes on main today (confirmed by reading it), so it doesn't reproduce Symlink to PHP binary isn't created #2788 — the PR body is upfront about this ("environment-specific... on devbox 0.16/0.17 with Lix"). Since this is the only test coverage for the php plugin, consider whether a regression test could assert the php binary specifically shows up under .devbox/nix/profile/default/bin (rather than only that devbox run php ... works), which is closer to what actually broke in the issue. Not blocking since the environment-specific repro likely isn't practical in CI.
• Note: I wasn't able to run go build/go test myself in this sandboxed environment (network/build commands require approval I don't have here), but the change is confined to plugin JSON/Nix templates with no Go code touched, so build risk is low. The PR description states go build ./... and the relevant go test packages were run locally and passed.

Overall: LGTM. The fix aligns the php plugin with the documented multi-output flake convention and the working example, and is scoped tightly to the actual bug.