| 17 Jul 2025 |
 emily | for sure for #1, it should probably get the token from the environment like other tooling
for #2 I guess it depends on the complexity of the code change and whether we worry about EA versions being added accidentally - if we don't expect that we'd want to exercise the functionality in Nixpkgs
| 21:28:11 |
| emily | In reply to @msgilligan:matrix.org
And, as far as making it available "out of tree", what would be the best way to do that? the standard thing these days would be to make a flake. we could expose generic builders for the relevant packages that can be supplied arbitrary versions from Nixpkgs if it would make that task easier l | 21:28:58 |
 msgilligan | Would (or could) that flake be an "overlay"? It would be nice if I could add 25-EA and then have packages like Gradle and JBang be configured to use that JDK. That (or a similar mechanism) would also allow the build of 25 to get some testing. | 21:30:55 |
| emily | it can be, but you don't need an overlay to use out of tree packages either | 21:33:41 |
| msgilligan | I know that raboof created an "out of tree" solution here, but I don't know how to use it from a flake and it seems more like a very separate thing, not something this is a "preview" of something that will move to Nixpkgs. | 21:34:35 |
| msgilligan | I think the ideal way would be able to access the PRs branch directly and I've seen flakes that use both a stable and unstable release of Nixpkgs, so I think that approach should work. That would also make it easier to rebase and to adapt for new EA releases after the current EA becomes GA. | 21:37:41 |
| emily | yeah, that very much works | 21:43:06 |
| emily | you don't necessarily need two Nixpkgses since GitHub has magic refs that represent the state if the PR was merged | 21:43:45 |
 Infinidoge 🏳️⚧️ | The unfortunate thing with PR branches vs overlays or grabbing directly is that PR branches usually aren't kept up to date, and usually don't follow with a standard stable branch | 21:43:47 |
| Infinidoge 🏳️⚧️ | Oh good magic ref, that works | 21:43:58 |
| emily | though in the presence of merge conflicts that doesn't work so great :) | 21:44:00 |
| Infinidoge 🏳️⚧️ | If flakes supported patches for inputs the world would be at peace | 21:44:20 |
| Infinidoge 🏳️⚧️ | But alas | 21:44:25 |
| Infinidoge 🏳️⚧️ | IFD | 21:44:26 |
| Infinidoge 🏳️⚧️ | I have hope for Fetch Tree, but only hope | 21:44:35 |
| emily | I don't think fetchTree changes anything there | 21:45:44 |
| Infinidoge 🏳️⚧️ | I think the ideal solution would be an out-of-tree repo exposing packages through flakes and an overlay, with a structure identical to how the packages would be in Nixpkgs, so they can be directly transferred in later | 21:45:47 |
| emily | honestly using the PR refs seems fine to me. I just, like, wouldn't deploy it in pros | 21:46:34 |
| emily | * | 21:46:39 |
| emily | but I wouldn't deploy an EA version in prod to begin with :) | 21:46:51 |
